> From: Std-Proposals <std-proposals-bounces_at_[hidden].org> on behalf of Chris Gary via Std-Proposals <std-proposals_at_lists.isocpp.org>

> I find it strange that the "{}" syntax was adopted instead of some variation on "%" or "introducer-then-parameters" instead of "scoped parameters".

The f-string draft is using it because it's what the current format-string syntax is in C++.

I assume C++ chose it because python used it (or because fmt used it, but fmt chose it because python used it).

Python chose it because Microsoft .Net used it for "Composite Formatting", two decades ago.

It's also used by other languages, as well as templating engines, etc.

> I also find "@" easier to spot in a language where it isn't often used elsewhere as opposed to even more curly braces.

Earlier on I had considered using a '@' or '$' for the delimiter instead of a colon, because they couldn't appear in an expression (at least, not yet).

But they _can_ appear in a string literal inside the expression:

    F"has key: {map.contains(\"a_at_b\")}";

So if the compiler is only doing stupid-simple scanning of the replacement-field, looking for a delimiter, it would have to keep track of double-quote pairs too, and that means it has to handle more escape sequences, etc. (it may well have to anyway, depending on how the WG decides to specify the processing logic, but I was trying to keep it very dumb/lazy parsing)

But anyway, I thought it would be better to try to keep to the existing C++ format-string syntax as much as possible. I think that's what users would expect?

-hadriel



Juniper Public