On Mon, Jan 4, 2021, 16:35 Steve Downey via SG16 <sg16@lists.isocpp.org> wrote:
Allowing escape sequences to be synthesized would be a surprising change in behavior. If we were designing this de novo it's just a choice, but the preprocessor is old, shared with C, and baked into lots of tools. 


I feel like I ask this question a lot, but
how much code would be impacted in practice?

Either way, I don't think it matters much:
- replacing escape sequences
- concatenating
- encoding

Seem to be a reasonable order of operations to me.
Might even be less surprising than doing the concatenation first!

However, if operator"" "" ends up being an issue, i would again ask how useful that feature is!

On Mon, Jan 4, 2021 at 9:54 AM Peter Brett via SG16 <sg16@lists.isocpp.org> wrote:
Please could someone remind me of the *downsides* of allowing escape sequences to be synthesized into string literals through pre-processor concatenation?

Many thanks,

              Peter

> -----Original Message-----
> From: SG16 <sg16-bounces@lists.isocpp.org> On Behalf Of Jens Maurer via SG16
> Sent: 19 December 2020 22:45
> To: Corentin Jabot <corentinjabot@gmail.com>; SG16 <sg16@lists.isocpp.org>
> Cc: Jens Maurer <Jens.Maurer@gmx.net>
> Subject: Re: [SG16] Handling literals throughout the translation phases
>
> EXTERNAL MAIL
>
>
> On 18/12/2020 10.33, Corentin Jabot wrote:
> > On Thu, Dec 17, 2020, 22:33 Jens Maurer via SG16 <sg16@lists.isocpp.org
> <mailto:sg16@lists.isocpp.org>> wrote:
> >
> >
> >     I'm working on a paper that switches C++ to a modified "model B"
> approach for
> >     universal-character-names as described in the C99 Rationale v5.10,
> section 5.2.1.
> >
> >
> > I thought sg16 agreed to not replace ucn until phase 5 a few meetings ago,
> did I completely missunderstood what sg16 agreed ?
>
> The difference is that we do not produce UCNs is phase 1.
> Instead, phase 1 simply produces Unicode scalar values.
> Any UCNs that appeared in the original source are replaced later.
>
> >     My current idea is to focus on the creation of the string literal
> >     object; that's when transcoding to execution (literal) encoding
> >     happens. All other uses of string-literals don't produce objects,
> >     so aren't transcoded.
> >
> >     In order to be able to interpret escape-sequences in phase 5/6,
> >     we need a "tunnel" for numeric-escape-sequences.  One idea would
> >     be to add "code unit characters" to the translation character set,
> >     where each such character represents a code unit coming from a
> >     numeric-escape-sequence.  The sole purpose is to keep the
> >     code units safe until we produce the initializer for the
> >     string literal object.
> >
> >     The alternative would be to delay all interpretation of escape-
> >     sequences to when we produce the initializer for the string
> >     literal object, but that also means we need to delay string
> >     literal concatenation until that time (see first item above).
> >
> >
> > Would that cause any issue? This would otherwise be my preferred solution!
>
> We currently support   operator "" "" ""   in [over.literal], for example.
> We'd need to make string-literal concatenation first-class citizens
> in phase 7 (e.g. making it a constant expression or so), which is a fairly
> large hammer.
>
> Jens
>
>
> --
> SG16 mailing list
> SG16@lists.isocpp.org
> https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/sg
> 16__;!!EHscmS1ygiU1lA!UD-
> 5R2q135Y6KFqLCSPTdN4MoF1skMz9Clm4f_oANDvBoEzgrct6vMkc9NQQMw$
--
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16
--
SG16 mailing list
SG16@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg16