It will be easier because you don't have to make a block for it every time you need to use it.
I feel like there are too many primitives. I preferred the time when blocks like map and for required libraries.
I agree, but it's so simple of a block that it takes longer to load up the editing interface than to write the block. It also takes longer to open the library and remove the extra blocks. The ONLY I would want this as a primitive is that I'm lazy. So, in favor of Snap's design motto (provide the basic primitives only so that the user can create everything else), I'd have to say I don't agree with you, @donotforgetmycode_sn. Sorry.
Oh, we (Jens and I) have this discussion repeatedly about every library block. From the beginning, I wanted to load the Tools library automatically on starting Snap!, but Jens didn't for efficiency reasons. What finally tipped the scale for the higher order functions wasn't really a pedagogic argument; it's that the primitives are so much faster than the versions written in Snap!. If we ever have a real compiler, that might tip the balance back the other way. Speed matters in particular for doing media computation on the pixels in a costume, or doing queries from huge online databases.
IGNORE, by contrast, is really fast even written in Snap!. And it's a neat lesson that even a procedure with no body at all can be useful!
We might revisit this after inventing hybrid primitives (they run in JS but they have an Edit menu option, and when edited you see the Snap! code).
What is the "ignore" block used for? Running reporters and not doing anything with the result.
I think you can put a ringified reporter in a run block.