Re: break/continue vs. try-always

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Sun, 08 Jun 2014 14:01:46 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> } 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.
> 
> The problem with that solution is that it propagates downward -- it's
> the inverse of break/continue propagating upward.  There may be layers
> of function scope in between the caller and the eventual break/continue
> that expect the current dynamic-scope behavior.

This is why I pointed out you could do

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


because the restore behaviour is in the caller.  It doesn't seem to me
any different from the fact that any option at all could be misset for a
particular type of function, so the function needs to set them up with
an emulation.

I wouldn't expect anything more than a very exceptional wrapper to break
and continue to rely on that behaviour.

pws