>
> Not allowing combination with R for raw literals. It seems like there
> is no real reason not to allow this. The purpose of R literals is to be
> able to have quotes and newlines in strings literals. You can use a R
> literal as the format string for std::format so it seems odd to not
> allow combining f/x and R, in which case the F or X would go between any
> U prefix and the R which must be last.
>

How would one specify a '{' in a raw formatting literal?
I'm not expecting to read escapes inside such things, and I'd find that to
be an odd workaround.

On Sun, Oct 15, 2023 at 3:58 PM Bengt Gustafsson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I have some comments regarding the limitations that you put on f/x
> literals. I see that these are made to reduce the implementation effort,
> but I don't think this outweighs the drawbacks of having to remember the
> restrictions. After all the implementation is done by a few programmers
> while the remembering of restrictions and all kinds of special cases
> increases the cognitive load for millions of programmers. In this case
> I'm referring to:
>
> 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.
>
> 2. Not allowing expressions in {} after the colon (what is called nested
> replacement fields). I don't actually see much implementation effort
> reduction in disallowing this (it is allowed in P1819). The code to
> interpret an expression inside a {} is already there and its result, to
> put the expression afterwards is exactly the same.
>
> 3. Not allowing combination with R for raw literals. It seems like there
> is no real reason not to allow this. The purpose of R literals is to be
> able to have quotes and newlines in strings literals. You can use a R
> literal as the format string for std::format so it seems odd to not
> allow combining f/x and R, in which case the F or X would go between any
> U prefix and the R which must be last.
>
> 4. Allowing macro expansion. This is of course a more natural limitation
> for implementers considering the translation phase you are aiming at.
> But it is not as obvious for programmers who will certainly picture this
> as a purely textual transformation, which it basically is. Yes it is
> probably more work to do this in the earlier parts of the preprocessor,
> but not overly so. Note that R literals did force preprocessor
> implementations to be updated, it's not that we never touch the
> preprocessor. Also, to evaluate the expressions in #if a stand alone
> preprocessor must already contain most of the machinery needed to figure
> out where an embedded expression ends, i.e. tokenization and parenthesis
> handling.
>
> 5. Escaping of quotation marks in the expressions. I'm a bit unsure of
> what is the best choice, but if handling of f/x literals is moved to an
> earlier stage of the preprocessor it would be _possible_ to handle
> quotation marks without quoting them. I think it would be an advantage
> to be able to write the expressions exactly the same as if they were
> outside the f/x literal. There is also a problem with parentheses inside
> such quotes (escaped or not) that needs to be discussed if "matching
> parentheses" is employed. For instance:
>
> F"{isLeft ? "(" : ")"}"
>
> or with escaping of
>
> F"{isLeft ? \"(\" : \")\"}"
>
> There is also the worst case scenario when the embedded string literal
> contains an escaped quote, for instance:
>
> F"{isSingle ? "'" : "\""}"
>
> or with escaping, I don't think this can work:
>
> F"{isLeft ? \"'\" : \"\"\"}"
>
> The problem here is that the escaping incurred by being inside a f/x
> literal crashes with the need to escape the quote in the expression
> being inserted. Parsing becomes (close to?) impossible.
>
> This suggests to me that not requiring quoting is the right choice, but
> this obviously requires the feature to be implemented entirely in the
> preprocessor.
>
> The alternatives is to further restrict the embedded expressions not
> allowing quoted strings in them, or at least not escaped quotation marks
> in those strings.
>
> 6. Not allowing encodings seems strange, especially as std::format is
> defined for char and wchar_t. The source code is still in the source
> character set and only after the expressions have been lifted out is the
> remaining literal converted to the specified character set depending on
> the prefix. There should be no issue in allowing all of the prefixes.
>
> 7. Not allowing locale also seems strange for X-literals as the literal
> has nothing to do with the locale specific formatting of inserted
> values. Even there is interaction between the formatting string after
> the colon string interpolation does not touch that part.
>
> In short only the first of your restrictions in chapter 4 is actually
> logical to me. Numbered inserts is actually not very useful as long as
> the first parameter to std::format is a literal, as its main use is to
> be able to shuffle the order of the inserted values around when
> translating the string to another (human) language. As translation is
> out of scope for interpolated literals (in a compiled language) this
> restriction is inconsequential given restriction #8, which is, as you
> write, obvious.
>
> Bengt
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>