[superamadeus]

Is there any discussion or in-depth explanation of the syntax choices? I understand that a goal was context free unambiguous parsing. But there are some things that surprise me.

For example, string interpolation:

    "Hello, (msg)$!\n"

Why “(msg)$” and not “$(msg)”? Surely the latter is easier to parse?

[frankjr]

https://github.com/hsutter/cppfront/wiki/Design-note:-Captur...

[ralferoo]

I think $() makes much more sense than ()$ in terms of parsing, when you see $ you're looking for a single word token, and $( you're parsing up to the matching )

Maybe it's not much extra workload, but ()$ requires you to pattern-match all bracketed content in a string as a possible capture, and the parser can't determine whether it's a capture or not until the $ or a matching close bracket. Consider parsing "((x)$)" would require parsing the entire string to determine the first bracket wasn't a capture, then we can treat just the first character as a literal, then we have to re-parse the rest of the string again, and can't be sure it's a capture until the $, and then we can evaluate it as a real expression and then continue with the final $.

Other interesting cases would be "(x+(x)$)" or even "((x+(x)$)$)". I'm not sure I could easily predict the parsing of latter, but prefix and permitted unbracketed single word variable names "(x+$x)" is clearer and the second would either be "(x+$(x)$)" or "($(x+$(x)))" both of which are explicit using the prefix form and could simplify to "(x+$x$)" and "($(x+$x))" where the intent seems clearer.

There's the precedent that many languages already use the prefix form which would help newcomers with familiarity, and in fact many of these languages wouldn't even need the brackets and $var would be sufficient, and I can't really see why the spec requires the brackets in the ()$ syntax in string literals but not for expressions in code.

[OskarS]

> Maybe it's not much extra workload, but ()$ requires you to pattern-match all bracketed content in a string as a possible capture, and the parser can't determine whether it's a capture or not until the $ or a matching close bracket.

You don't have to: you can also just parse the string backwards.

[lifthrasiir]

That raises more questions though... Like, why does the capture syntax have to be attached to the captured element?

Rust for example has a single `move` syntax for all-capture vs. no-capture toggle, e.g. `|x| x + foo` (`foo` is stored as a reference) vs. `move |x| x + foo` (`foo` is moved into the closure). While I do want an additional mode for uniformly applying specific methods (typically `.clone()`) for captured elements, that is almost enough for typical closures.

Also, if my reading of the documentation is correct, `$` has to be attached to each occurrence of captured elements. Like, `:(i) = i + foo$ * (foo$ + 1)`. Doesn't that look strange? It is even possible to mix two variants of captures like `:(i) = i + foo$ * (foo&$* + 1)`, and it's not entirely obvious to me what will happen to `foo$` when `foo&$*` is updated. Treating these "upvalues" as a sort of an implicit structure (e.g. `$.foo`) is much more consistent, and a prefix form `$foo` can be regarded as its shorthand.

[breatheoften]

What does "for later use" mean?

One thing I've noticed recently is that pretty much no language has a good way to simultaneously define a nested structure and assign that structure a name "for later reuse".

For example -- suppose I'm dealing with some serialized data structure that come from some external system. Very likely the data model behind this value involves "nested values" which have themselves have some type of which might be reused in multiple places by that external system.

When the goal is to just solve problems -- the approach i like to take is to focus on the values i want to consume and produce -- which might themselves contain lots of nested types each with some amount of reuse ...

I'd really like a language feature that supports simultaneously defining a type where it's relevant within some other data structure _and also allows_ giving that embedded thing a name for independent reuse ...

I wonder if this postfix $ syntax is related to that use case at all ...

(... this comment a speculation based on names of things only without even reading the whole article ...)

[loeg]

Raises more questions honestly. This looks more different from today’s C++ than Rust.

[epage]

I feel like consistency goes too for losing the visual parsing benefits of special syntax. Otherwise, we might as well adopt lisp's syntax.

[zarzavat]

Something about foolish consistencies…

The priorities of a programming language syntax are to be readable first, consistent second.

When it comes to syntax that is used more frequently then the importance of readability increases, and the importance of consistency drops, because people will become familiar with the syntax through frequency of use, so there is no need for them to be guided by consistency. Yet they will be reading the code more often.

When it comes to syntax that is used infrequently then consistency is of more importance because you want users to be able to intuit the syntax. Since it will be infrequently used, the readability is of lesser impact.

[dataflow]

I feel like there are more options than just the ones he listed. Like "Hello ${name}" or "Hello `name`" or "Hello {`name`}"...

[superamadeus]

Oh, fantastic. Thank you!