for / while else doesn't make sense

[Erik]

On 20/05/16 00:51, Gregory Ewing wrote:
> It's not so bad with "else" because you need to look back
> to find out what condition the "else" refers to anyway.

With my tongue only slightly in my cheek, if it was desirable to 
"fix"/clarify this syntax then I would suggest adding some optional 
(existing) trailing keywords to 'else' in this context that spells it out:

for item in seq:
     if foo(item):
         break
else if not break:
     nomatch()

I would rule out "elif not break" - this is just about adding additional 
trailing words to existing syntax to spell it out (which might be a good 
teaching aid as well as turn into personal preferred style).

I guess that it _could_ be a syntax error to reference "break" if the 
for/while loop does not contain the keyword in its body - this could 
actually address one of the "confusing" things mentioned in this thread, 
like:

seq = []
for item in seq:
   pass
else if not break:
   pass

# Syntax error - "break" referenced in "for/else" clause but not present 
in loop body.


Someone also pointed out that there are other flow control mechanisms 
that could prevent the 'else' from being executed: "return" and "raise". 
One could extend the above to allow one or more of those to be specified:

   else if not break or return or raise:

That looks like a lot of noise, but again it could help make code more 
explicit (both to the human reader, and to a compile-time check):

for item in seq:
   if foo(item):
     break
   if bar(item):
     return
else if not return:
   pass

# Syntax error - extended "for/else" clause does not reference "break", 
which exists in loop body.

I would _not_ suggest that the above should ever mean "if it doesn't 
return, this code is executed regardless of whether 'break' happened" - 
one would remove the 'else' clause altogether for that.

"raise" is more problematic as an exception can always be raised by 
pretty much _anything_ in the body without the keyword being present. 
Perhaps "or raise" is just a completely benign, optional keyword for the 
completists. Or perhaps it's simply not mentioned at all and is always 
implied (as is true of exceptions in other constructs such as plain 
"if/else", and just generally).


The additional keywords would effectively just be a static checked 
filter - the original bare "else" would effectively mean "else if not 
any_flow_control_out_of_the_loop" (which is what it means today).


In summary: Adding the "if not" extension is the suggestion, with 
"break" as the filter. "return" as an additional filter is a possibility 
which may add something, "raise" as an additional filter is a 
possibility which probably doesn't add anything (and may actually be 
distracting).



I'm not entirely sure if _I_ like this yet (there are some things I've 
suggested that I like and some I'm not sure about and some I don't like 
but I've mentioned them anyway) - I'm just throwing it out there ;)

E.