|Subject:||[@LARRY] phasers/loop controls in routines that accept Callables|
I came across an interesting doc Issue[^1] showcasing `next` working inside the Callable given to `Any.first`. The reason it works is pure accident and other loop controls don't work, nor do the phasers. `grep -FR 'Callable' src | wc -l` gives 128 matches, and I'd guess at least some of those are a similar situation where loop controls/phasers either interfere with the internals in the method or are not handled. For example, some phasers are currently not handled[^2] by .grep method. So the question is, what do we do about these? Implementing handlers for everything would be giant buggy mess and pessimization, often done to handle cases no one really needs. Catching stuff in CONTROL just to throw is also messy and may interfere with stuff that does want to propagate those exceptions further up the food chain. Or lastly, and this is the option I favour, don't do anything. We implement handlers for controls/phasers only where they make a lot of sense and document the places where they work. In all the other cases, were a Callable is taken by routines, we simple declare that control exceptions/phasers are undefined behaviour and should not be used. IMO the latter category includes the grep[^2] phasers as well; if someone really needs to phaserize a grep callable, rewrite it as a for/gather/take thing.