Date: Wed, 16 Oct 2013 16:49:23 -0700
On 10/14/13, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> > On 10/14/2013 03:18 PM, Gabriel Dos Reis wrote:
> > > Revision based on feedback attached.
> > > - UCN token splicing is made conditionally supported with
> > > implementation defined semantics, instead of just ill-formed
> > > as proposed earlier.
> >
> > Aren't there just two options: Either this becomes a UCN by token
> > splicing, or it stays a sequence of individual characters? Can't
> > we just say that?
>
> A third option is "ill-formed". I don't think we should get down to
> that level of detail here. I would rather leave it to implementations
> and tools whether they want to support clean mode (diagnose), garbage
> mode (individual characters), or make sense of it
> (implementation-defined semantics.)
For the preprocessor, I would rather not see undiagnosed differences in
behavior. Wouldn't it be best to simply poll the vendors and see if
they are okay with standardizing on "UCN from splicing"?
> > On 10/14/2013 03:18 PM, Gabriel Dos Reis wrote:
> > > Revision based on feedback attached.
> > > - UCN token splicing is made conditionally supported with
> > > implementation defined semantics, instead of just ill-formed
> > > as proposed earlier.
> >
> > Aren't there just two options: Either this becomes a UCN by token
> > splicing, or it stays a sequence of individual characters? Can't
> > we just say that?
>
> A third option is "ill-formed". I don't think we should get down to
> that level of detail here. I would rather leave it to implementations
> and tools whether they want to support clean mode (diagnose), garbage
> mode (individual characters), or make sense of it
> (implementation-defined semantics.)
For the preprocessor, I would rather not see undiagnosed differences in
behavior. Wouldn't it be best to simply poll the vendors and see if
they are okay with standardizing on "UCN from splicing"?
-- Lawrence Crowl
Received on 2013-10-17 01:49:26