dchar undefined behaviour

[tsbockman via Digitalmars-d]

While working on updating and improving Lionello Lunesu's 
proposed fix for DMD issue #259, I have come across a value range 
propagation related issue with the dchar type.

The patch adds VRP-based compile-time evaluation of integer type 
comparisons, where possible. This caused the following issue:

The compiler will now optimize out attempts to handle invalid, 
out-of-range dchar values. For example:

dchar c = cast(dchar) uint.max;
if(c > 0x10FFFF)
     writeln("invalid");
else
     writeln("OK");

With constant folding for integer comparisons, the above will 
print "OK" rather than "invalid", as it should. The predicate (c 
 > 0x10FFFF) is simply *assumed* to be false, because the current 
starting range.imax for a dchar expression is dchar.max.

So, this leads to the question: is making use of dchar values 
greater than dchar.max considered undefined behaviour, or not?

1. If it is UB, then there is quite a lot of D code (including 
std.uni) which must be corrected to use uint instead of dchar 
when dealing with values which could possibly fall outside the 
officially supported range.

2. If it is not UB, then the compiler needs to be updated to stop 
assuming that dchar values greater than dchar.max are impossible. 
This basically just means removing some of dchar's special 
treatment, and running it through more of the same code paths as 
uint.

At the moment, I strongly prefer #2, but I suppose #1 could make 
sense if people think code which might have to deal with invalid 
code points can be isolated sufficiently from other unicode 
processing.