> Thanks for the feedback. See comments below.
>
> Richard Smith <richardsmith_at_[hidden]> writes:
>
> | 2.2/1: Forming a UCN through a line splice works in both
> implementations of
> | UCNs that I know of (EDG's and Clang's). Making it ill-formed would
> invalidate
> | these implementations. Same with forming a UCN through token
> concatenation.
> | Suggestion: make this valid, to match existing implementations.
>
> so, you want "implementation-defined" here?
> Do real programs actually rely on this working?

All that is required by "making it ill-formed" is that a diagnostic
message is required. The message could even praise the programmer:
"Congratulations for using our special feature which splices UCN tokens."
There are no requirements on the contents of the message, and it does
warn the programmer that the construct is not portable.
 
> | 2.5/2: I'm a little worried that people might be relying on this, for
> instance
> | in macro arguments that are only ever stringized. I can't find an
> | implementation that rejects this by default (though GCC and Clang
> reject it in
> | their pedantic modes).
>
> the reason for suggesting this resolution is that it has worked well in
> pedantic modes on real programs. The only time I was made aware of a
> difference was with the "old K&R" preprocessor which worked on
> characters, not tokens -- GCC has had separate for that program anyway
> since the rework by both Zack and Neil, more than a decade ago.
>
> | 16.1/4: Should the case where 'defined' is created through macro
> expansion make
> | the program ill-formed, or should we specify its behavior? (The
> natural
> | behavior seems to me to be that a 'defined' token appearing through
> macro
> | expansion should be treated like any other identifier, and be
> replaced by 0)
>
> that, to me, is surprising; not natural :-)
> I did consider it, including an implementation-defined behavior, but
> concluded that just adds to the pile of non-portability with not much
> benefit...

Agreed.

> | 16.8/4: In some circumstances it is desirable to #undef __DATE__ and
> __TIME__
> | (if you want a deterministic, reproducible build). Are we OK with
> that making
> | the program ill-formed?
>
> I would think so. Implementations are still free to let their users to
> opt out.

Agreed.