Subject: Re: [isocpp-core] New draft revision: D2029R2 (Proposed resolution for core issues 411, 1656, and 2333; numeric and universal character escapes in character and string literals)
From: Corentin (corentin.jabot_at_[hidden])
Date: 2020-07-01 03:23:52
On Wed, 1 Jul 2020 at 10:14, Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
> On 01/07/2020 09.44, Corentin wrote:
> > On Wed, 1 Jul 2020 at 09:29, Jens Maurer via Core <core_at_[hidden]
> <mailto:core_at_[hidden]>> wrote:
> > We should be clear in the text whether an implementation is allowed
> to encode
> > a sequence of non-numeric-escape-sequence s-chars as a whole, or
> > each character is encoded separately. There was concern that
> > doesn't address stateful encodings, where the encoding of string
> > i+1 may depend on what string character i was.
> > We should be careful not to change the behavior here.
> > Encoding sequences allow an implementation to encode <latin small letter
> e, combining accute accent> as <latin small letter e with acute>
> Agreed. We should probably prohibit doing that for UTF-x literals,
> but I'm not seeing a behavior change for ordinary and wide string
> > Which is not the current behavior described by the standard.
> Could you point me to the specific place where the standard
> doesn't allow that, currently?
> [lex.string] p10
> "it is initialized with the given characters."
> for example doesn't speak to the question, in my view.
My reading of the description of the size of the string
> > I think this is a much more important aspect (whether we think an
> implementation should be able to do that or not) than trying to describe
> the idiosyncrasies of all encodings.
> Fine. My answer is "yes, an implementation should be allowed to do that".
> (And, as QoI, implementations will avoid shooting their customers in the
> foot more often than not.)
SG16 list run by email@example.com