>
> For example P2561, or the '?:' "Elvis" operator that some compilers even
> support today.
>

I'd push for "operator ??", not that I have really anything but an opinion
to offer.

Dial "$" for "$tring"?

F"has key = { map.contains( $"a:b" ) }";

Its an unusual character sequence, and stands out. The reader is already
parsing an F string.
I'm not sure if this is also what you had in mind with using "$", though.



On Sun, Oct 15, 2023 at 11:11 PM Hadriel Kaplan via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi Bengt,
> I'll split up the response into separate emails...
>
> > From: Bengt Gustafsson <bengt.gustafsson_at_[hidden]>
>
> > 1. The problem with the colon in the ternary ? operator. I don't think
> > it is much more complicated to handle this than to count matching
> > parentheses. The extra implementation to find the ? and then pass over
> > the next : on the outer level should be rather easy to do.
>
> Unfortunately ternaries are not the only problem. I just showed a ternary
> because I thought it would be the most-common case of syntax ambiguity.
>
> But there are at least two other problems:
>
> 1. C++ may add other use-cases for single colons or question-marks in the
> future, that would affect this parsing. For example P2561, or the '?:'
> "Elvis" operator that some compilers even support today.
>
> 2. If we only trivially-scan the replacement-field for the colon
> delimiter, then even a colon appearing within an internal string literal
> would cause a problem:
>
> F"has key = { map.contains(\"a:b\") }";
>
> At least, assuming we don’t require the scanning to have to keep track of
> and ignore string literals when looking for a delimiter.
>
> ---
>
> And I say "at least two problems" because it's assuming I haven't missed
> some other valid scenario for a single-colon to appear in an expression. :)
>
> -hadriel
>
>
>
> Juniper Public
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>