For loop syntax

[dutkalex]

EDIT:

After a lengthy discussion with @MaxSagebaum and @hsutter, I realized that the main point I was trying to articulate is that we are very close to having a general unified syntax for control flow, which would naturally yield the usual for, while and if as special cases. The most natural syntax I have managed to come up with is:

some_label:                        // 1. introduce a name
(copy i : index_type = 0)          // 2. introduce local variables
for (elm : elm_type) in some_range // 3. introduce current element
while i < N                        // 4. stop condition
next i++                           // 5. increment stmt
if some_condition                  // 6. filter condition
{ some_statement; }                // 7. body

The only modification proposed here is the spelling of the third line. This particular proposition was motivated by the following arguments:

1. it is very human readable
2. it is very close to the existing cpp1 range-based for loop syntax
3. it does not introduce special cases where some combinations allow brace-less single-statement bodies as is currently the case
4. it naturally resolves the inconsistency in the placement of the next clause

The main argument against this specific proposition is that introducing the element before the range breaks the "always start with something that already exists" principle, which reduces toolability. Maybe we can find a better proposition which would not have this drawback. What do you think?

ORIGINAL COMMENT:

Hi folks!
Here are some concerns about the current design of for loops, following the discussion in #1063. For loops in cpp2 are built as follows:

loop_name: for <some_range> next <inc_stmt> do ( <in, copy, out, inout, move or forward> current_element ) {
  // body
}

The loop_name: prefixed label and the next incrementation clause are optional. In the case of single-statement bodies, the curly braces are too. This syntax is very closely related to the function syntax, as for loops are essentially built as for <range> do <lambda_function>. The rationale behind this functional design is rooted in the fact that most for loops can be written as the traversal of a range. This is the motivation for the range-based for loop syntax in cpp1, which is a safer alternative to the traditional C syntax and more directly expresses intent:

for ( auto [const][&, &&] current_element : some_range ) {
 // body
}

Note however that the cpp1 version reads left to right ("for current_element in some_range"), while the cpp2 version does not. Note also that a do keyword is added in the cpp2 version which:

1. Enables the omission of the curly braces for single-statement loops, which is inconsistent with all the other control flow structures
2. Can be misleading because the do keyword connotes a do while loop

Non range-based cpp2 for loops are spelled as follows:

(copy i := <init>) while <stop_condition> next <inc_stmt> {
  // body
}

Note that the syntax is isomorphic to the C for loop syntax:

for ( auto i = <init>; <stop_condition>; <inc_stmt> ) {
  // body
}

Note also that the for and do keyword are absent of this second flavor of for loops, as this for loop has become a while loop in cpp2. This implies that the curly braces are now mandatory, even for single-statement loops. Finally, note the inconsistent position of the next clause between the two kinds of for loops.

[dutkalex]

I believe we could fix several (all?) of these issues with a syntax such as:

loop_name: for <in, copy, out, inout, move or forward> <current_element> : <some_range> {
  // body with mandatory curly braces
}

Indeed, this syntax:

1. Reads left to right
2. Is closer to cpp1's range-based for loop syntax
3. Is consistent with the other control flow constructs: mandatory curly braces and consistant while, next and if optional clauses
4. Does not require a misleading do token

Moreover, introducing an index_range(start, stop) helper, this syntax would nicely incorporate index-based for-loops:

for i : index_range(start, stop) next i++ { // next clause is useless here, just there to highlight consistency
  // body with mandatory curly braces
}

[gregmarr]

Everything after do is the a parameterized statement, so the (word) is part of the loop body. So I would have pronounced it as: "... do this loop body, which takes that word and if i is odd outputs i and word"?

Interesting. That's different than what's in the documentation now, which is for range do (e) statement.
I'm strugging to figure out how I would put this information into the documentation. I've tried a few different methods:
for range [next statement] do parameterized_statement

• where parameterized_statement is a statement that can have a single named parameter that accepts an element of the range, and an optional if condition.
• the thing after do is an unnamed function that takes no parameter or a single parameter that accepts an element of the range, and returns nothing (but then how do I put the if on it?)

Is this parameterized_statement used anywhere else in the language?

I don't think it covers do...while, right? I debated whether to support do...while which does have different semantics and is less often used. Any code that naturally uses do...while (because it wants to execute the body at least once) can be written using the other loops too, but would require code duplication (manually unroll the first iteration) and/or an extra variable so it's less simpler/clear than do...while for those cases.

Brainstorming:

Not terribly clean because you can have two whiles and the } doesn't terminate the statement, you have to see if it's followed by a while, and then it's ambiguous with a following while loop:
while i < N // 4. stop condition
next i++ // 5. increment stmt
if some_condition // 6. filter condition
{ some_statement; } // 7. body
while i < N; // 8. stop condition

Indicate that the test is after the loop:
[while | while_post_loop**] i < N // 4. stop condition

Indicate that you don't test the first time (more explicit about exactly how it's different, since this is the real difference):
[while | while_at_least_once**] i < N // 4. stop condition

** subject to bikeshedding. :)

[hsutter]

a valid use case for a do while loop in real code

There's one in cppfront. I definitely agree that "execute this code at least once" is less common.

Any code that naturally uses do...while (because it wants to execute the body at least once) can be written using the other loops too, but would require code duplication (manually unroll the first iteration) and/or an extra variable so it's less simpler/clear than do...while for those cases.

I believe all you need to do to turn a do while into a simple while is give a name to the boolean condition.

Right, that's the "and/or an extra variable" option. It does work. One downside of that, besides the extra variable making the code slightly more indirect, is that it puts the boolean condition into the loop body, which requires reading the code to answer questions like "what's the loop termination condition?" and "is that termination variable assigned anywhere else on multiple paths?"... Having while condition (either at the front or the end of the loop) is declarative, we can know how the loop operates does without reading the body.

Another way to avoid the extra variable, and make it easier to see where in the loop body the exit points are calculated, is to change the loop to while true and in the body use if !boolean_condition { break; }. That still puts the condition into the loop body, but you can grep for break to find the loop exits.

Then the question just is, is the result clearer than just being able to write do...while ?

[hsutter]

Everything after do is the a parameterized statement, so the (word) is part of the loop body. So I would have pronounced it as: "... do this loop body, which takes that word and if i is odd outputs i and word"?

Interesting. That's different than what's in the documentation now, which is for range do (e) statement.

Can you elaborate on what's different? "For each element of range do this loop body, which takes that element and performs statement" seems right to me?

[dutkalex]

One downside of that, besides the extra variable making the code slightly more indirect, is that it puts the boolean condition into the loop body, which requires reading the code to answer questions like "what's the loop termination condition?" and "is that termination variable assigned anywhere else on multiple paths?"... Having while condition (either at the front or the end of the loop) is declarative, we can know how the loop operates does without reading the body.

I would argue that naming the condition is also an opportunity to be more expressive... I may be biased here, but I would be more comfortable reading the second option than the first, just because I get some information on what the loop does before diving into the body

do { 
  // body
} while maybe_obscure_boolean_expression;

(meaningful_name_for_condition := true) while meaningful_name_for_condition{
  // body
  meaningful_name_for_condition = maybe_obscure_boolean_expression;
}

There's one in cppfront.

And actually, looking at your example from cppfront, I could not really get a good grasp of what the loop does, because of this very issue of complex boolean logic... (and the fact that I did not try very hard ^^)

[gregmarr]

Can you elaborate on what's different? "For each element of range do this loop body, which takes that element and performs statement" seems right to me?

It was specifically (word) is part of the loop body vs for range do (e) statement. To me, statement is the loop body, not (e) statement.

[hsutter]

BTW, I don't think this thread got to a loop syntax question I actually wrestled with more (sorry if I missed it), which is the location of next.

For do...while loops, the while and the next naturally go at the end, which is where the test occurs and where the next happens.

For the other loops, the next is at the front to keep everything together. But does that make the lexical flow (up front) different from the actual execution flow (at the end of each loop iteration)? That bothered me a little, until I decided that conceptually it's equivalent to view it as happening at the beginning of each "next" (i.e., not the first) iteration of the loop. (And, sure, before the next 'while` is executed, but oh well.)

So I ended up feeling okay about next being grouped with for/while, whether they both appeared at the front or at the end.

[dutkalex]

The proposed place for the next right after the while never felt strange in my case. Coming from for (int i = 0; i < N; i++) having them together feels quite natural. What bugs me is seeing it in the middle of the for ... do syntax, because it is inconsistent and because it separates the range and the element.

[dutkalex]

BTW, how does the if filter condition fit in a do ... while loop? Is this legal?

do
if filter_condition {
  // body
} while stop_condition;

And what is the behavior if the first iteration does not pass the filter?

[hsutter]

Quick ack: The do...while requires {} around the loop body.

do {
  if filter_condition {
    // body
  }
} while stop_condition;

[bluetarpmedia]

I'm not convinced it's desirable to unify range-for loops (hereafter foreach) with while conditional loops. (Apologies if I've misunderstood the proposal!)

To me, the main benefit of a foreach loop (see also: the std::for_each algorithm) is that the reader doesn't need to look for a stop condition to understand what the loop is doing. In other words, it's raising the level of abstraction because we're giving the loop a meaningful name and therefore making the code easier to read.

---

In terms of syntax, I do prefer for (elm : elm_type) in some_range (or similar). I read that as "for each element in some_range".

If you scan all the foreach examples from different programming languages on Wikipedia the vast majority of them use a for item in collection syntax. I don't say that as some kind of "appeal to the majority" argument, but rather to say I think programmers are most familiar with that style because of its prevalence, so adopting that syntax in Cpp2 would (presumably) help programmers transitioning to it.

I'm a big fan of ranges and fluent-style / array / sequence programming but I don't think those examples add to the argument of keeping the current syntax with the collection first, because Cpp2 already has a ranges equivalent syntax to match C++. (Actually, IMO, it's an improvement as Herb showed above with UFCS.)

Instead, I think we should be comparing the C++ range-for loop to Cpp2's, especially with the perspective of C++ programmers transitioning to Cpp2, and my view is that it makes it easier for C++ programmers to rewrite code in Cpp2 by having the more common "for item in collection" syntax.

---

Regarding do...while I think it's rare but necessary so I'm in favour of keeping it in Cpp2. I've used it in production code for situations where you need to run an operation and, if it fails, retry that operation for a maximum number of attempts before returning an error to the client.

Finally, I've been meaning to open a suggestion for this, but since it's on topic... I'd really love half-open and closed ranges (as in, numeric intervals) support for Cpp2 foreach loops:

for 0..100 do (i: int) {}   // Today's syntax

for (i: int) in 0..100 {}   // Alternate

Like in Rust and Swift.

[MaxSagebaum]

Strong disagree. The syntax is not consistent as is (next keyword, lamdas with no prefix :, brace-less for loops) and if we want to keep concepts separate the for and while loop should not accept an if filter, and the for loop should not accept a next clause

So for the for loop and a function:

range := ...;
func: (a) = std::cout << a << std::endl;

for range do (cur) { std::cout << a << std::endl; } // Writing it out
for range do (cur) { func(cur) };                   // Calling a function

do currently introduces the loop body with a parameter list and a body.

If we require the declaration syntax at this place:

for range do :(cur) = { std::cout << a << std::endl; } // Writing it out
for range do :(cur) = { func(cur) };                   // Calling a function
for range do :(cur) = func(cur);                       //  Can now be simplified

Since : introduces a lambda it should be possible to write.

for range do func;                //  Looks a little bit weird to me, but in terms of what should be allowed it would make sense
for range do func(_1);            //  Maybe using a wildcard here will help
for range do func(_);             //  or
for range do func(...);           //  or

Since, we only need to introduce : into the do syntax and get other benefits, I call this consistent. With your current proposal this would no be possible.

A side note: If you change your initial post and give there a summary, you should hint at this in some comment. People might miss this especially if they just read the gitlab mails. Here, edits do not appear and you only get the initial message.

[hsutter]

Quick ack:

If we require the declaration syntax at this place:

for range do :(cur) = { std::cout << a << std::endl; } // Writing it out

That used to be the syntax, see the 2022 talk here for example.

I remember writing/presenting rationale for why I changed it, but I can't find the writeup now... it boiled down to the unification of functions and block scopes, and that : always introduces a new thing (e.g., a closure object) whereas here the semantics are that what follows is a block (it can't really be a closure, because then return and break and continue wouldn't work; and when I was initially using this syntax those keywords did the right thing which demonstrated that it wasn't really a closure).

[MaxSagebaum]

Ok, that makes sense. But my argument was more along the lines that it is closer to the current function syntax.

[hsutter]

Yes, functions and scopes/blocks are intentionally unified and so the syntax is very much a subset of the current function syntax.

Aha, I found the writeup (it's hard to find even for me because this is the section I found hardest to find a good place for in the docs): From functions to local scopes, and back again.

In the terms used in the first set of examples there that starts from the full function syntax and successively removes parts, for's body is a local immediate (immediately executed, not stored) block of code (aka function body), so it doesn't have : and =.

In the terms used in the first set of examples there that starts from the ordinary statement/block syntax and successively adds parts, for's body is a parameterized statement/block.

That's my current mental model, anyway. When I initially made it the full function syntax, I hadn't yet implemented the "immediate function / parameterized block" step, and thinking about it I realized that for doesn't GET-A closure that bundles up a piece of code to pass around elsewhere, it HAS-A parameterized block that it executes immediately right here in this scope.

Pasting as screenshot below for convenience:

[dutkalex]

This is an elegant unification between for loops and functions, but which comes at the expense of consistency in the syntax of control flow structures. I don't really see any practical benefits to this, while having an incoherent syntax to express control flow yields more complex language rules, which will be harder to teach and probably will make tooling more complex. I believe this is a net loss, as this unification is purely artificial IMHO

[gregmarr]

Musing about this a bit more, I want to call out something from one of my other comments. We're discussing unifying loop syntax, so can we find a syntax that fits all of them? The difference between while (x) { something; } and do { something; } while(x); is often described as "test the conditional after the loop instead of before it", but can be equally be described as "don't test the condition before the first time you enter the loop". If that is the only difference, and all of the other loop setup remains the same, then can we just highlight that difference, and not change the entire syntax? That could be a different keyword than while, or a contextual keyword after it. That way we have all of the loop mechanics up front, instead of way down the function. For example, the do/while in this repo when viewed on github.com doesn't fit on my screen. I can see the do or the while, but not both.

Conceptually, if you haven't already learned the difference between while(x) {} and do {} while(x), is it inherently obvious that the condition is evaluated before the loop in the first case and after it in the second one? Is it obvious that next means do this after the loop? Should we be even more different and explicit?

loop 
[init <variables>]
[over <range> [as <element>]]  (if we want the range first, or [foreach <element> in <range>] if we can keep the current order)
[before [terminate on <condition>] [skip on <condition>]]
[after [<expression>] [terminate on <condition>]]
{ <body> }

for  words
next i++
do   (word)
if   i % 2 == 1         // if i is odd
{                       // do this loop body
    std::cout << "counter: (i)$, word: (word)$\n";
}
//  prints:
//      counter: 1, word: [Betty]

loop 
init (i := 0, j := 0) // j just to show that we can do more than one
over words as (inout word: type)
before skip on i % 2 == 1         // if i is odd
after i++
{
    std::cout << "counter: (i)$, word: (word)$\n";
}

[hsutter]

Conceptually, if you haven't already learned the difference between while(x) {} and do {} while(x), is it inherently obvious that the condition is evaluated before the loop in the first case and after it in the second one? Is it obvious that next means do this after the loop? Should we be even more different and explicit?

Quick ack: To me, they are evaluated in the same place in both cases... between the loop iterations. They differ on whether they're additionally evaluated on first entry of the loop.

[dutkalex]

Some idea I had this morning while walking to work: if starting with something that already exists is important for toolability, why not go all the way and spell the traversal of a range as:

my_range.for_each( :( i: int ) = {
  // body
} );

It should be easy to call under the hood std::for_each thanks to UFCS. What do you think?

[bluetarpmedia]

Yeah that's nice, and in fact the ranges version already works today:

main: () -> int = {
    v: std::vector = (1, 2, 3);
    using namespace std::ranges;
    v.for_each(:(i: int) = std::cout << "(i)$ ");
    return 0;
}

[dutkalex]

Shouldn't this be our default for expressing range-based for loops then?

[MaxSagebaum]

As Herb mentioned already. This does not allow to use loop control keywords like continue or break any longer. Therefore he decided to drop the : and have special bodies for for loops.

[dutkalex]

I think there are two cases to distinguish here:

1. General purpose for loops which require continue, break, filtering etc.
2. Range-based functional for loops which are a (very important) special case, and which can be expressed more directly with a more declarative syntax, because of their narrower scope

This proposition is only about the latter

[gregmarr]

Shouldn't this be our default for expressing range-based for loops then?

It does make sense to use the algorithms in the situations where they apply. Even if it makes sense to use range-for as a language feature instead of for_each as a library feature, this still applies to all the other algorithms.

This proposition is only about the latter

Your proposed syntax already works, you just need using namespace std::ranges, and it needs to be something that is a range.

Here are the different syntaxes in their shortest forms. There's not a whole lot of difference. The biggest difference is that the first 4 are language features, the 5th is a library feature.

    // cpp2 range-for now
    for my_range do (i) std::cout << "(i)$ ";

    // Your syntax from the first post
    for (i) in my_range { std::cout << "(i)$ " }

    // my more-verbose unified syntax
    loop over my_range as i { std::cout << "(i)$ " }

    // my element-first more-verbose unified syntax
    loop foreach i in my_range { std::cout << "(i)$ " }

    // foreach algorithm
    using namespace std::ranges;
    my_range.for_each(:(i) = std::cout << "(i)$ ");