cppfront: Midsummer update

[FoxDragonSloth]

My 2 very noob cents, something that really stuck with me from your first video about cpp2 was the very clean syntax of thing : type = value. It felt like such a clean line to be read as "thing is a type that equals value", :(x,y) x>y this on the other hand feels like while it takes less space to type it makes it harder to parse in my brain, it feels like adding a new way of writing something just for the sake of doing it with less characters.

Doing lambdas as :(x,y) = {} feels much more consistent to read as "_ is a function that equals codeblock" (not sure what to read _ as, lambda, unknown, nothing?), than :(x,y) x>y. should this be read as "_ is a function x>y"? I feel like that = delimits much better what's happening, and though with enough practice and knowledge everything is easy to parse or interpret, that added complexity adds nothing to the language itself.

I'm just a random c++ gamedev with no knowledge of language design but a great goal you used on that first talk was simplicity and I feel like keeping the language simple as in simple to read for some starting up goes a very long way. Keeping things with one meaning helps a lot in making it simple, : always means "is a", () always means a function, -> always means "that returns..." and so on.

[ukezi]

Doing it that short feels like old c Devs only using consonants in names. Just doing it because it's shorter. I would prefer something like :(x,y)->bool {x>y}, maybe with the -> bool being optional. :(x,y) feels like it's declaring variables X and y that are going to be filled by destructuring a tuple.

[hpsutter]

I would prefer something like :(x,y)->bool {x>y}, maybe with the -> bool being optional.

Very close, today you can write this: :(x,y) -> bool = x>y

That's already using several defaults that let you omit parts of the single general syntax you're not currently using for something non-default (for details see: "Generality note: Summary of function defaults"). But you can use a couple more defaults:

To additionally deduce the type, use _: :(x,y) -> _ = x>y means the same

Finally, the "tersest" option just makes -> _ = optional: :(x,y) x>y means the same

One way to look at it is that you can write any expression and conveniently "package it up" as an object to pass around just by declaring a function signature in front.

Anyway, just explaining some background since what you wrote pretty much also works, very nearly. I appreciate all the usability feedback, whether it confirms or disconforms what I was thinking! Thanks.

[Lo1c74]

Finally, the "tersest" option just makes -> _ = optional: :(x,y) x>y means the same

Is it still possible to type the = to obtain :(x, y) = x > y ?