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

That same scanning is what a brain needs to do. So, definitely, it needs to
be KISSed into not needing a second look. An "introducer-parameters"
replacement field would have been easier to deal with, since its "found
introducer, now match what follows against a simple pattern until some
space". I'm not sure how the double-quotes would be an issue, but it sounds
like you're trying to just copy Python.


> 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?


Sure, I suppose now that the paint has finished drying. I've gotten used to
whatever is already in-place, which really means anything now.

What I would like out of something like this: No new framework or runtime
coupling. No new syntax that performs allocations. Just syntax-only
WYSIWYG, and the translation of WYS to WYG is just an exercise in
rearranging symbols. I was thinking of something along the lines of infixes
between literal fragments, since this would work well with a simple
preprocessor (token-pasting aside). OTOH, large applications that handle
text for presentation with format strings do so parametrically, (format
strings with numbered arguments in different places depending on locale) so
this would be more of a thing for small project readability.

It also helps if it doesn't look itself like a regular expression. Not that
the status-quo has this problem per-se, they still don't read well with
find & replace (each "{" has to be escaped, but who uses regex anyway?).

On Sun, Oct 15, 2023 at 9:48 PM Hadriel Kaplan <hkaplan_at_[hidden]> wrote:

> > From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
> of Chris Gary via Std-Proposals <std-proposals_at_[hidden]>
>
> > 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
>