[SUGGESTION] `for` loop is ambiguous with lambda syntax

[msadeqhe]

Preface

Cpp2 has the following control structures:

if CONDITION { ... }
else if CONDITION { ... }
...
else { ... }

while CONDITION next STEP { ... }

do { ... }
while CONDITION next STEP;

for ITEMS do: (ITEM) = { ... }

While I always thought that for loop gets a lambda, and because of that I started to think that Cpp2 should have user-defined language constructs. But NO, hopefully the statement block of for loop is not a lambda.

All control structures of Cpp2 have statement blocks, therefore we don't need to capture anything inside the statement block of for loop.

How to reproduce?

It's an example:

#include <iostream>
#include <vector>
#include <string>

main: () = {
    items: std::vector<int> = (1, 2, 3);
    r: = 10;

    for items do: (item) = {
        r = 0;
        std::cout << item << "\n";
    }
}

A typical programmer would think that : (item) = { ... } is a lambda because of its similarity with lambda syntax, but hopefully it's not. Cpp2 generates the following code:

auto main() -> int{
    std::vector<int> items {1, 2, 3}; 
    auto r {10}; 

    for ( auto const& cpp2_range = items;  auto const& item : cpp2_range ) {
        r = 0;
        std::cout << item << "\n";
    }
}

Suggestion Detail

I didn't know I should create a bug report or a suggestion for ambiguous problem of for loop. By the way I created a suggestion.

I suggest to change the syntax of for loop from:

for ITEMS do: (ITEM) = {
    ...
}

to something consistent with other control structures such as one of the following syntax:

for ITEM keyword ITEMS {
    ...
}

for ITEMS keyword ITEM {

}

In which:

• keyword for the first option can be in, of, iter or etc.
• keyword for the second option can be next, each, loop or etc.

Any other syntax which is similar to other control structures, is good.

Why do I suggest this change?

Because:

1. The statement block of for loop syntax : (item) = { ... } is ambiguous with lambda syntax. A typical programmer expects to capture variables inside it.
2. The statement block of for loop syntax : (item) = { ... } is inconsistent with other control structures which their statement block are simply { ... }.

Your Questions

Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code?

No.

Will your feature suggestion automate or eliminate X% of current C++ guidance literature?

Yes absolutely. It would make control structures to be consistent with each other in addition to simplification of guidance:

• { ... } will be for the statement block of control structures, therefore variables don't have to be captured.
• But : (args) = { ... } will be for lambdas, therefore variables have to be captured. for loop breaks this rule.
• Expressions in control structures (e.g. the expression after next keyword in while loop) won't be evaluate at first evidence, and they can be evaluated multiple times.
• But expressions in other places (e.g. for variable initialization or function arguments) will be evaluated one time at first evidence.

Considered alternatives

The other alternative solution is to make the statement block of for loop to be actually a lambda, which is weird and inconsistent with other control structures.

[JohelEGP]

The syntax is supposed to make the language more regular, as a for loop's body is parametrized on the element being iterated.

I did find it a bit weird, but only because of the association with function expressions and the knowledge they're lowered to Cpp1 lambda expressions.

Otherwise, I think it's a win. The function syntax is regular. At namespace scope and type scope, they declare functions. At statement scope, they're currently banned. As expressions, they work and permit captures. And finally, they work as the for loop's parametrized statements' body (no scope introduced, and I suppose captures not permitted).

[msadeqhe]

Otherwise, I think it's a win. The function syntax is regular. At namespace scope and type scope, they declare functions. At statement scope, they're currently banned. As expressions, they work and permit captures. And finally, they work as the for loop's parametrized statements' body (no scope introduced, and I suppose captures not permitted).

IMO that's why it complicates the language. It just feels like another static keyword in Cpp1 which has many meanings in different places.

[JohelEGP]

Consider the upcoming template for. In Cpp2, that's a noop. cppfront would just have to permit <T> before :(item), and emit template before for in that case.

EDIT: It's https://wg21.link/P1306, for....

[msadeqhe]

That's nice, but { ... } doesn't cause trouble for for... in generic programming:

func: <T: type...> (args: T...) = {
    for... arg: T in args {
        //: statements...
    }
}

or this one:

func: <T: type...> (args: T...) = {
    for... args next arg: T {
        //: statements...
    }
}

or any other syntax without : (arg) = { ... }.

[JohelEGP]

Sorry, that was a bad example. "Expansion statements", proposed for Cpp1, operates on values. So it'd probably be a matter of permitting for... in Cpp2, too.

[hsutter]

Thanks for the feedback. The status quo is by design, because the body of a range-for loop (not a do or while loop) is already conceptually a function invoked once per element in the range.

Note that capture is already not allowed in all functions. In particular, named functions already don't allow capture. Perhaps it helps if you view the body of a for loop as being a function named do?

[msadeqhe]

Although it's not possible to have nested functions in Cpp2, but yes, it helps if I view it as a function named do.

[hsutter]

BTW, Cpp2 will have local functions. They're pretty much there, I just ban them as a 'temporary alpha limitation' only because I haven't been motivated to prioritize the task of emitting them as a lambda and making sure they can capture. It shouldn't be hard, but I've wanted to drive other things like meta functions first. Also, they have a pretty easy workaround (as in Cpp1 today) which is in the error message you get if you try to write one:

(temporary alpha limitation) local functions like 'f: (/*params*/) = {/*body*/}' are not currently supported - write a local variable initialized with an unnamed function like 'f := :(/*params*/) = {/*body*/};' instead (add '=' and ';')

That said, I have said the same about other features and then ended up prioritizing and implementing them anyway already because they came up in issues... squeaky wheels do get grease, and programmers asking for a feature and showing concrete use cases is new information that justifies revisiting priority. So if you want cppfront to prioritize implementing nested functions, get friends to open issues and show use cases. 😁

[filipsajdak]

Or... propose implementation in PR. It might save some Herb time (hopefully). I can help in reviewing the code.

[msadeqhe]

Thank you. I think I have to write a conclusion for future readers if they come up to this issue.

I'm reading again this comment from @JohelEGP:

Otherwise, I think it's a win. The function syntax is regular. At namespace scope and type scope, they declare functions. At statement scope, they're currently banned. As expressions, they work and permit captures. And finally, they work as the for loop's parametrized statements' body (no scope introduced, and I suppose captures not permitted).

And I put it next to this informative comment from @hsutter:

BTW, Cpp2 will have local functions. They're pretty much there, I just ban them as a 'temporary alpha limitation' only because I haven't been motivated to prioritize the task of emitting them as a lambda and making sure they can capture. It shouldn't be hard, but I've wanted to drive other things like meta functions first. ...

So I should give up to separate functions and lambdas for learning Cpp2, because they are implementation detail. To simplify the learning progress I should keep in mind that there is only functions (either named or unnamed). Thus I should change my comment from:

Yes absolutely. It would make control structures to be consistent with each other in addition to simplification of guidance:

• { ... } will be for the statement block of control structures, therefore variables don't have to be captured.
• But : (args) = { ... } will be for lambdas, therefore variables have to be captured. for loop breaks this rule.
• Expressions in control structures (e.g. the expression after next keyword in while loop) won't be evaluate at first evidence, and they can be evaluated multiple times.
• But expressions in other places (e.g. for variable initialization or function arguments) will be evaluated one time at first evidence.

... to this one:

Conclusion

Cpp2 have functions and local functions (either named or unnamed). { ... } is a statement block. : (args) = { ... } is a function. The following rules apply to them:

• Expressions (e.g. for variable initialization, function arguments and ...) will be evaluated one time at first evidence in their place, because they have to be evaluated before they can be passed to a function. Also to access local variables which are from outer function scope, we have to capture them inside statement blocks (e.g. either { ... } or : (args) = { ... }):

...
variable: = 0;
forrr(items, : (item) = {
    ...
    // We have to capture `variable`.
    x: = variable$ + 10;
    ...
});


count: = 0;
// `count < 10` will be evaluated only one time at first evidence in their place.
// `count++` will be evaluated only one time at first evidence in their place.
// So this doesn't do the same thing that `while` does.
whileee(count < 10, count++, : () = {
    ...
});
...

• But in control structures, expressions (e.g. the expression after next keyword in while loop) won't be evaluate at first evidence, and they can be evaluated multiple times (they are somehow macros), because of that, to access local variables from outer function scope, we don't have to capture them inside statement blocks (e.g. either { ... } or : (args) = { ... }):

...
variable: = 0;
for items do: (item) = {
    ...
    // We don't have to capture `variable`.
    x: = variable + 10;
    ...
}

count: = 0;
// `count < 10` will be evaluated multiple times.
// `count++` won't be evaluated at first time but it will be evaluated later multiple times.
while count < 10 next count++ {
    ...
}
...

In this way Cpp2 language is consistent with simple rules. Thanks for your guidance from those comments.

[msadeqhe]

Or... propose implementation in PR. It might save some Herb time (hopefully). I can help in reviewing the code.

@filipsajdak, You're right, it's the best way to suggest features in Cpp2. But I hope I could... I don't have any experience or study in transpilers, compilers and etc... I'm going to read the source code to try my luck to understand it.

[filipsajdak]

@msadeqhe I did not have much experience with it as well. I can help.

[JohelEGP]

Preface lost in an accidentally deleted comment. Recovered:

So, I'd say, in the happy path:

The Cpp2 range-based for statement

label? 'for' expression next-clause? 'do' unnamed-declaration

is equivalent to (after lowering to Cpp1)

{
  label?
  for ( parameter-declaration : expression ) {
    { compound-statement }
    next-clause?
  }
}

where parameter-declaration and compound-statement
are the immediate productions that make up the unnamed-declaration.

That said, I'd prefer a description that doesn't rely on Cpp1. I'd like to think that you don't have to learn Cpp1 to learn Cpp2, before learning Cpp1, and such. Much like we say about teaching C++ and C.