Re: break/continue vs. try-always

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Sun, 08 Jun 2014 11:41:23 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> Sorry, I'm still not getting it.
>...
> Under what circumstances would I need to use try-always to cancel
> my own evil return?

I'm not really getting you're not getting it.  Why does it have to be
your own return?  Isn't the point of a sandbox to prevent something you
*don't* control?  That's the case in the test code:  what triggered this
thread was a "continue" that's causing a continue outside the scope of
the test.  I don't see why you should force people to create a new
function scope to do this when you don't do that for break and continue;
they should be consistent.

However, what *I'm* missing is that break and continue propagate outside
a function --- so you can't trap them that way anyway.  That seems to me
a straight bug, since it implies a fairly groteseque intermingling of
multiple levels, but it does happen in other shells, too, so evidently
we have to treat it as a feature.

If you like the idea of function scope as a sandbox, it seems me that a
neater way to handle this would be to add an option to force break and
continue to respect function scope.  Then no new syntax is required.
Provide you define that the new option (call it localloops for now) is
applied in the outer function on return from the inner, you can do
everything with


setopt localoptions localloops
() {
   # call user code
}
# localloops is restored on return here and used to cancel breaks /
# contflag before resuming user code at this point.


e basta.  That's also very simple to implement, with no new globals or
variables, and the only namespace affected is one we have complete
control over.  Furthermore you can set it once at the top of your code
and the affect propagates as far down as you need it: you could
explicitly unset it in the sandbox function if you wanted to provide a
100% pristine environment, but otherwise you only need to modify
existing code at one point.  I think to get this to be robust localloops
would have to be defined as one of the few options, like localoptions,
that always get restored on return from a function.

Of course the surrounding code doesn't actually have to be in a function
scope, though I set localoptions assuming it was; only the inner scope
is important.

pws