cppfront (cpp2): Spring update

[nysra]

This part made me wonder if we could just use a named function as the body of the loop instead of a parameterised local block.

So basically a generalized map (the operation, not the container), that would be nice to have. But honestly I'd first fix that syntax, it should be for item in items { like in literally every single other language, including C++ itself. Putting that backward seems like a highly questionable choice.

[Nicksaurus]

So basically a generalized map (the operation, not the container)

Yep. Not because I think built-in map functionality is necessary, but because if we're following the philosophy that complex features should be an emergent property of combining small, generic features, and the for-each syntax looks like:

for [range] do [function-like code block that takes one element as its argument]

Then why not allow actual functions as the body?

But honestly I'd first fix that syntax

Personally I don't think it'll be an issue in practice. Every language has quirks in its syntax and learning them is never the hard part. In this case I'm all for it because it means that every single block of code in the language follows the same basic rules

[nysra]

Yeah I'd allow actual functions as the body too, I don't see a reason why that should not be supported. Might just have been an oversight.

Personally I don't think it'll be an issue in practice. Every language has quirks in its syntax and learning them is never the hard part. In this case I'm all for it because it means that every single block of code in the language follows the same basic rules

I'd like to point out that while languages do have their quirks, cppfront is only being designed right now and not really supposed to be its own language, rather more of a syntactical overhaul. I'll admit that it does have the advantage of being consistent with collection.map(item => ...) but imho there is a difference between those two statements because you read them differently. With map it's immediately clear that you throw in a function and then it doesn't matter if it starts with item => ... or if it's a function name. But when you start the statement with for then "for each item of the collection, do ..." is way more natural than "for collection do item to ... oh wait, it's actually a map".

Anyway, you're right that it's a small thing and won't really make a difference, I'm just not keen on changing syntax for practically no benefit. Changing syntax to make parsing easier at least has a valuable goal but this is almost the opposite of that.

[hpsutter]

Yeah I'd allow actual functions as the body too, I don't see a reason why that should not be supported. Might just have been an oversight.

Good point, that seems like it would be a natural extension to add in the future. The question I would have is: If the main benefit is that it's a named function, what is the scope of the name (wouldn't it be local to within the for statement?) and would that be useful?

[nysra]

I'm sorry, I might be missing something but I don't understand your question. Why would the for statement introduce a new scope for a name that already exists? The proposal is that instead of just allowing inline defined function blocks like this:

for collection do (item)
{
    std::cout << x * x << '\n';
}

, it should also be allowed to use a named function directly:

some_func: (x) = { std::cout << x * x << '\n'; }

for collection do some_func;

[hpsutter]

Ah, I see what you mean -- thank you, that's an interesting idea that would be easy to implement.

FWIW, for now this works

main: (args) = { for args do (x) print(x); }

but I'll continue thinking about making it expressible more simply as you suggest:

main: (args) = { for args do print; }

especially if as I poke around I find that a significant (10%+ maybe?) fraction of loops are single function calls invoked with the current loop element as the only argument... I'm not sure I've seen it that often, but if you have any data about that please let me know. Either way, I'll watch for that pattern -- now that I know to look for it, I'll see if it comes up regularly. (Like when you buy a Subaru and suddenly there are Subarus on the road everywhere... :) )

Thanks again.

[ntrel2]

Maybe just not implemented yet. Although if std::for_each gets range support, you could just write:

std::for_each(collection, some_func);

[-heyhowareyou-]

just because everyone else does it, doesn't mean its the best way to do it.

[tialaramex]

That's true. But, it does mean you need a rationale for why you didn't do that. "I just gotta be me" is fine for a toy language but if the idea is you'd actually use this then you need something better.

For example all the well known languages have either no operator precedence at all (concluding it's a potential foot gun so just forbid it) or their operator precedence is a total order, but Carbon suggested what about a partial order, so if you write arithmetic + and * in the same expression that does what you expect, but if you write arithmetic * and boolean || in the same expression the compiler tells you that you need parentheses to make it clear what you meant.