Concatenation of ubyte[] to char[] works, but assignation doesn't

[Marc Schütz via Digitalmars-d-learn]

On Tuesday, 6 October 2015 at 05:38:36 UTC, Jonathan M Davis 
wrote:
> Your suggestion only works by assuming that the result will fit 
> in a char, which doesn't fit at all with how coversions are 
> currently done in D. It would allow for narrowing conversions 
> which lost data. And there's no way that Walter would go for 
> that (and I don't think that he should). VRP solves the problem 
> insofar as it can guarantee that the result will fit in the 
> target type and thus reduces the need for casting, but simply 
> assuming that char + int will fit in a char just doesn't work 
> unless we're going to allow narrowing conversions to lose data, 
> which we aren't.
>
> If we were to allow the specific conversions that you're 
> suggesting but only when VRP was used, then that could work, 
> though it does make the implicit rules even screwier, becauses 
> it becomes very dependent on how the int that you're trying to 
> assign to a char was generated in the first place (straight 
> assignment wouldn't work, but '0' - 40 would, whereas 'a' + 500 
> wouldn't, etc.). VRP already makes it a bit funky as it is, 
> though mostly in a straightforward manner.

I see, this is a new problem introduced by `char + int = char`. 
But at least the following could be disallowed without 
introducing problems:

     int a = 'a';
     char b = 32;

But strictly speaking, we already accept overflow (i.e. loss of 
precision) for ints, so it's a bit inconsistent to disallow it 
for chars.