Date: Fri, 29 Jul 2022 20:04:36 +0200
On 29/07/2022 19.10, Tom Honermann via SG16 wrote:
> EWG is scheduled to review P1819 (Interpolated Literals) <http://wg21.link/P1819> during its 2022-08-04 telecon. I believe EWG will only be performing an initial review to provide feedback to the author (CC'd). I won't be able to attend, but encourage other SG16 regulars to do so.
>
> It is not obvious to me whether there are text related concerns sufficient to justify SG16 spending time on this paper. Please respond with any opinions you might have. If EWG expresses disinterest in the paper, SG16 won't spend time on it unless I hear overwhelming support that would suggest desire to challenge EWG's direction in that case.
>
> One question SG16 could address is whether support for interpolated strings should be extended to all string literal kinds. The paper proposes f"text {expression}" but is silent regarding whether something like u8f"text {expression}" or fL"text {expression}" should be supported (and if so, whether there is an ordering requirement between the encoding-prefix and the interpolated-string prefix).
As a first-level concern, this is an EWG concern, because the new facility
is simply specified to perform some desugaring into a lambda, so SG16-related
concerns do not appear at that level. (They come in later when the text
is actually passed to std::ostream or so, but the paper is a bit silent
on the details here.) In any case, the desugaring would work unchanged
with u8 and L string literals.
I notice that braces already have special meaning in string literals,
at least sometimes:
"\N{SPACE}"
"\x{deadbeef}"
I'm wondering how the parsing would actually work, and
whether we can have these fancy escapes in the brace part
of the new string literals.
Oh, and this paper creates a situation where we need to
create phase 7 tokens out of a sequence of characters,
essentially, something which usually happens partly in phase 4
or so, but what we have appears to be a phase 7 facility
(is it?) Some clarity on the mechanics would be appreciated.
Jens
> EWG is scheduled to review P1819 (Interpolated Literals) <http://wg21.link/P1819> during its 2022-08-04 telecon. I believe EWG will only be performing an initial review to provide feedback to the author (CC'd). I won't be able to attend, but encourage other SG16 regulars to do so.
>
> It is not obvious to me whether there are text related concerns sufficient to justify SG16 spending time on this paper. Please respond with any opinions you might have. If EWG expresses disinterest in the paper, SG16 won't spend time on it unless I hear overwhelming support that would suggest desire to challenge EWG's direction in that case.
>
> One question SG16 could address is whether support for interpolated strings should be extended to all string literal kinds. The paper proposes f"text {expression}" but is silent regarding whether something like u8f"text {expression}" or fL"text {expression}" should be supported (and if so, whether there is an ordering requirement between the encoding-prefix and the interpolated-string prefix).
As a first-level concern, this is an EWG concern, because the new facility
is simply specified to perform some desugaring into a lambda, so SG16-related
concerns do not appear at that level. (They come in later when the text
is actually passed to std::ostream or so, but the paper is a bit silent
on the details here.) In any case, the desugaring would work unchanged
with u8 and L string literals.
I notice that braces already have special meaning in string literals,
at least sometimes:
"\N{SPACE}"
"\x{deadbeef}"
I'm wondering how the parsing would actually work, and
whether we can have these fancy escapes in the brace part
of the new string literals.
Oh, and this paper creates a situation where we need to
create phase 7 tokens out of a sequence of characters,
essentially, something which usually happens partly in phase 4
or so, but what we have appears to be a phase 7 facility
(is it?) Some clarity on the mechanics would be appreciated.
Jens
Received on 2022-07-29 18:04:42