Date: Fri, 13 Oct 2023 14:11:20 +0200
Hi,
The first thing that came to my mind reading your proposal was "what if
the expression between braces contains a legit single colon? Is there a
subset of valid expressions that can be used in a replacement field?"
You address the first point in the section Error Cases in a way that is
unsatisfying in my opinion. Quote:
For example the first line of the following has a single semi-colon
: between 2 and 6, which will be treated as separating an optional
format-spec, and will thus convert but fail to compile later:
F"{check() ? 2 : 6}"; // ERROR: converts, but fails to compile later
F"{check() ? 2 : 6:}"; // ok
I like the simplicity of your approach but IMHO we cannot have such
approximate subset of expressions for replacement-fields. This should be
either any expression (good luck parsing that ;)) or else something like
a single identifier (but then frustration will arise).
Julien
The first thing that came to my mind reading your proposal was "what if
the expression between braces contains a legit single colon? Is there a
subset of valid expressions that can be used in a replacement field?"
You address the first point in the section Error Cases in a way that is
unsatisfying in my opinion. Quote:
For example the first line of the following has a single semi-colon
: between 2 and 6, which will be treated as separating an optional
format-spec, and will thus convert but fail to compile later:
F"{check() ? 2 : 6}"; // ERROR: converts, but fails to compile later
F"{check() ? 2 : 6:}"; // ok
I like the simplicity of your approach but IMHO we cannot have such
approximate subset of expressions for replacement-fields. This should be
either any expression (good luck parsing that ;)) or else something like
a single identifier (but then frustration will arise).
Julien
Received on 2023-10-13 12:11:23