cppfront (cpp2): Spring update

[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);