Allow for and while loop to return value (without discussion of keyword names)

[JelteF]

Introduction

I noticed #961 didn't seem to go anywhere because of the discussion about the name of the new block. That's why I just started working on an RFC with the new block name that IMHO seemed to have the least issues, namely the !break one. However, I found out a lot of behavioural details where not actually decided on or discussed.

What this discussion is about (spoiler: not names of keywords)

This is why I want to start a new thread to discuss these details and not the names of keywords. The names used in this issue are not meant as final keywords for an RFC. They are simply meant to allow a discussion without confusion. After the issues here are settled, the names for the keywords can be discussed again in #961 or in a new issue.

Problems

The new proposal would allow for and while to return a value with the break statement, just like proposed for loop in #1624. We need extra behaviour because for and while can exit without a break. However, this can happen in two different ways. Either the loop body is never executed (for with an empty iterator or while with a false condition at the start). Or the body is executed at least once, reaches the end of the loop body or a continue statement and then the loop stops (e.g. because it's out of elements or the condition has become false).

Solutions

For the case where the body is never executed another block is required that can return a value, this block is from here on called noloop. For the cases where the loop would be executed I see three main solutions. These are below with short names that are used in the rest of this issue between brackets:

1. Use the same noloop block as is use in the other case. ("noloop")
2. Use a second new block, from here on called nobreak. ("nobreak")
3. Use the value from the last statement that is executed, which can be continue. ("last-statement")

Then there are also two combinations possible of the options option above:

1. Make the nobreak block optional and "noloop" when it is not added. ("nobreak-noloop")
2. Make the nobreak block optional and "last-statement" when it is not added. ("nobreak-last-statement")

My opinion on these solutions

The "noloop" option seems like the worst choice, as it does not allow to differentiate between the two different cases. The "nobreak" option seems better in this regard as it allows to have different behaviour for both cases, but is more verbose in cases where the behaviour should be the same. The "nobreak-noloop" solution allows to have different behaviour for both cases, but is concise when this is not needed.

The "last-stament" option has a big usability advantage over the previous ones, because it allows returning of a value used in the last iteration. However, this comes with the disadvantage that when this is not needed all possible endpoints need to return the same value, i.e. the end of the loop and all continue statements. With the "nobreak-last-statement" solution you can work around this disadvantage by using the nobreak block.

This reasoning is why I think the solutions can be ordered from most desirable to least in the following order:

1. "nobreak-last-statement"
2. "last-stament"
3. "nobreak-noloop"
4. "nobreak"
5. "noloop"

Please comment if you have other ideas that could be used, or you have a different opinion en the proposed solutions.

[vitiral]

If the loop executes without being entered then the break never get's entered, which means that !break block makes complete sense. I would not special case this.

There is no other cases where a loop can exit without breaking -- except for return or break 'location which are irrelevant because the value of the break is never used.

I'm a little confused about this, other than the name of the !break block, there isn't much confusion (in my mind) about the syntax or structure. It would simply be something like:

let x = while i < 10 {
    if i == 6 {
        break "found";
    }
    if i == 3 {
        return Err("I was odd <= 3");
    }
    i += 2;
} !break {
    "not found"
};

There is no need for a noloop in that case (because !break covers it -- if it didn't enter the loop it also didn't encounter the break so would go to the !break)

[JelteF]

You might be right. The main reason why I thought special casing it would be nice, was so you could use the last iterator value as the return value in case nothing was found. Like the following:

let x = for i in [1, 4, 3, 2] {
    if i == 6 {
        break 6;
    }
    i + 10
} noloop {
    0
}

However, I'm not able to quickly think of a real use case for this. And it would also mean that the last statement needs to be executed each loop execution although it is only used the last time.

[vitiral]

that is the precise reason that !break needs to exist though. Your example requires !break, because that is what handles not encountering any break statements. The noloop would be separate and could not have anything to do with "the last iterator value" -- if the loop never executed then there would not be a "last iterator value"!!

You are proposing adding an additional branch in the case that the loop is never entered (noloop). However, this case is already covered by !break -- since if it didn't enter the loop it also didn't encounter break -- so I don't think it would be a good idea.

The "last loop value" is a non-starter anyway IMO -- it would be extremely confusing to work with and non-intuative.

[burdges]

Ick! I strongly prefer doing this sort of thing with return via closures or nested function in languages with those, way more clear and declarative than some strange keyword soup. If I saw one of our grad students using this sort of language feature, then I'd maybe make them use a closure instead.

I suppose #1624 seems okay because loop already denotes an unfamiliar loop, so everyone expects strange flow control, but even there I'd hope tail call optimizations eventually make people loose interest in this loop return value business.

That said, if one wants this sort of feature, there are two reasonable options that avoid needing any keywords :

If you like expressions everywhere, then just make for and while return an enum that describes what happened. I'd suggest just an Option<T> where T is the type of the final expression in the body, and the type supplied by breaks and continues, so None always means the loop never ran, and or_else(), etc. all work. You might consider something more complex, but.. why? You need a value from continue anyways. It'd interact with say #2974 but so does if now. Appears Option<T> gets messy here, but an enum the compiler handled special could avoid breaking existing code.

If you're less dedicated to expressions, and happy to ask for more breaks, then #1624 could be tweaked to allow :

let x = 'a { 
    for i in ... {
        ...
        if foo { break `a bar; }
        ...
    }
    baz
};

In both these cases, there is much less ambiguity for someone reading the code who comes from another language that may do other things.

[vitiral]

@burdges what do you think of this:

let x = if y > 10 {
    "small"
} else {
    "big"
};

This is "expressions return values" and is a core principle of rust control flow. These RFC's aim to make it even more clear.

The enum doesn't work, as has been discussed in #961

[notriddle]

I have to disagree pretty heavily with anyone proposing last statement.

First of all: it's not backwards compatible.

Second: it can't borrow anything that the conditional also borrows. For example, we should be able to do this:

let k = for i in &mut v {
    if i == x { break i }
} else {
    x
}

This isn't possible to duplicate with the last statement, because the value in the last statement needs to be held in a temporary variable while the condition is evaluated (i borrows the iterator, preventing next() from being called on it until it's gone). So while the version I have would work, it wouldn't work for this:

let k = for i in &mut v {
    if i == x { break }
    i
} noloop {
    x
}

The big problem is that it desugars to this:

let vi = v.iter_mut();
let mut k;
let mut ran = false;
while Some(i) = vi.next() {
    if i == x { break }
    k = i;
    ran = true;
}
if !ran { k = x }

Except the compiler knows k always gets initialized.

[JelteF]

It could easily be made backwards compatible. It would only be enabled when
break returns a value or when the noloop block would be added.

Your second statement is a very good reason not to do that though.

On 7 Oct 2016 4:52 am, "Michael Howell" notifications@github.com wrote:

I have to disagree pretty heavily with anyone proposing last statement.

First of all: it's not backwards compatible.

Second: it can't borrow anything that the conditional also borrows. For
example, we should be able to do this:

let k = for i in &mut v {
if i == x { break i }
} else {
x
}

This isn't possible to duplicate with the last statement, because the
value in the last statement needs to be held in a temporary variable while
the condition is evaluated (i borrows the iterator, preventing next()
from being called on it until it's gone). So while the version I have would
work, it wouldn't work for this:

let k = for i in &mut v {
if i == x { break }
i
} noloop {
x
}

The big problem is that it desugars to this:

let vi = v.iter_mut();let mut k;let mut ran = false;while Some(i) = vi.next() {
if i == x { break }
k = i;
ran = true;
}if !ran { k = x }

Except the compiler knows k always gets initialized.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1767 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG8JtGTqeBLlVXWum42KGAQkTYr7yWnks5qxbP7gaJpZM4KQNhr
.

[nagisa]

One thing to note (wrt keywords) is that since the last RFC we’ve added our first contextual keyword. Although I wouldn’t recommend adding another, it is still an option to consider.

As far as behaviour goes, the @notriddle’s point is fair and has no solution (you oughtn’t work around the borrowchecker here). Remembering the result of last expression in every iteration is probably something that will not happen for this reason. This makes result-ful for and some while loops significantly less useful as well.

Probably the only viable thing to consider is running that extra block if the loop wasn’t exit through break EXPR.

[vitiral]

Yes, the only viable syntax (with all possible complications) is:

let x = while i < 10 {
    if i == 6 {
        break "found";  // x == "found"
    }
    if i == 3 {
        return Err("i was odd <= 3"); // x will never be set
    }
    if i == -1 {
        panic!("negative numbers!"); // x will never be set
    }
    i += 2;
} !break {
    // only run if `break` never returned a value in above
    // loop (including if the loop was never entered)
    "not found" // x == "not found"
};

The only real discussion is whether there must be a ; after breaks with values -- which I think there should be (just like there is for return

[Ericson2314]

return .. and panic!(..) doesn't need semicolon in your example though.s

[vitiral]

#1624 (comment) discussed this, and you are right -- ; is not necessary for return, therefore it shouldn't be necessay for break.

I had been of the opinion that it was necessary, I think it is just conventional.

[taralx]

I believe with the current compiler architecture it would be possible to discriminate between loops whose values are used (and thus require type unification) and those whose values are not used (e.g. due to use of ;). It seems to me that this would provide the better ergonomics.