On Wed, 22 Jul 2020 at 13:45, Paul Moore <p.f.moore@gmail.com> wrote:

On Wed, 22 Jul 2020 at 13:18, Mathew Elman <mathew.elman@ocado.com> wrote:
>> Ones that retain else on loops are bad because
>> they end up providing two (typically equally confusing) ways of doing
>> things.
>
> I don't think this is the case. I agree that adding an alternative to `else` just to have an alternative is not a good fix, but adding explicit ways to refer to when breaking from the loop would make the use of `else` as it already is clearer.
>
> For example, breaking the change into 2 parts:
> 1. Adding `elif` to the `for...else` and `while...else` statements seems a logical extension. Guido has even said that the else in loops was invented by reasoning the connection of `if` to `while` (and then `while` to `for`). Perhaps this should be in its own discussion so as not to clutter this thread?

IMO, allowing

for ...
elif x == 2:
do something

to mean "if we didn't break out of the loop, and x is 2" would be
really confusing.

I don't think this would be any more confusing than `for...else` already is, and `while...elif...else` still seems like a logical extension of `while...else`.

x=0

while x < 10:

delta = get_delta(x)

if delta == 0:

break

x += delta

elif x%2:

print(f"{x} is odd and > 10")

else:

print(f"{x} is even and > 10")

And to have the elif after a loop be limited to a
different set of conditions than "ordinary" elif would *also* be
really confusing.

Absolutely! I would not suggest limiting it to any special cases. Hence why I split up the change. Adding a way to also use the elif to check the state of the loop is a separate discussion. Be that by using `break` as a special boolean or some other way.

> 2. Adding a way to use this new `elif` to check the state of the loop. Possibly including if it was broken out of or if it was never entered. Such as having special local variables that are only defined in the block/frame of the loop.

Same logic here - if we allow "elif not break" (for example), it would
be really confusing to *arbitrarily* only allow that if the elif is
attached to a loop. So we need to define what

if x == 2:
do something
elif not break:
what?

means in general code. And that means inventing rules for the scope of
"break as an expression".

And in a similar vein, what does it mean to
pass "break" to a function?

def invert(flag):
return not flag

for
...
elif invert(break):
...

That is fair enough, like I have said I am not attached (though others may be) to the idea of using `break` as a special boolean. Would it be more feasible to have a variable that persists beyond the scope of the loop and is not `break` but something else? For example, and this is not 100% serious but something like : `iter.broken`, `iter.enetered` etc.

It's not that any of these things are *reasonable* to do, it's that
all the special cases needed to disallow them would be confusing, and
if we *didn't* disallow them, all of the rules needed to give them
meaning in (conceded) unreasonable places would be confusing.

The trick here is *not* to look at the case that you expect the
construct to be used in - obviously it'll look good to you in that
context, if you like the idea at all. What you need to look at is all
the other ways it could be applied, and verify that the costs justify
the improvement that you saw when you first encountered the idea.

Good point, I think this is a well made argument for *not* making `break` have a second meaning.

Notice:
This email is confidential and may contain copyright material of members of the Ocado Group. Opinions and views expressed in this message may not necessarily reflect the opinions and views of the members of the Ocado Group.

If you are not the intended recipient, please notify us immediately and delete all copies of this message. Please note that it is your responsibility to scan this message for viruses.

References to the "Ocado Group" are to Ocado Group plc (registered in England and Wales with number 7098618) and its subsidiary undertakings (as that expression is defined in the Companies Act 2006) from time to time. The registered office of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, Hatfield, Hertfordshire, AL10 9UL.