dmd 1.046 and 2.031 releases

[Charles Hixson]

Steven Schveighoffer wrote:
> On Thu, 16 Jul 2009 08:49:14 -0400, bearophile 
> <bearophileHUGS at lycos.com> wrote:
> 
>> I'm playing with the new D2 a bit, this comes from some real D1 code:
>>
>> void main(string[] args) {
>>     int n = args.length;
>>     ubyte m = (n <= 0 ? 0 : (n >= 255 ? 255 : n));
>> }
>>
>> At compile-time the compiler says:
>> temp.d(3): Error: cannot implicitly convert expression (n <= 0 ? 0 : n 
>> >= 255 ? 255 : n) of type int to ubyte
>>
>> You have to add a silly cast:
>>
>> void main(string[] args) {
>>     int n = args.length;
>>     ubyte m = (n <= 0 ? 0 : (n >= 255 ? 255 : cast(ubyte)n));
>> }
>>
>> In theory if the compiler gets a smarter such cast can be unnecessary.
>>
> 
> I don't see how, doesn't this require semantic analysis to determine 
> whether implicit casting is allowed?  I think you are asking too much of 
> the compiler.  What if the expression was instead a function call, 
> should the compiler look at the function source to determine whether it 
> can fit in a ubyte?  Where do you draw the line?  I think the current 
> behavior is fine.  The D1 code probably works not because the compiler 
> is 'smarter' but because it blindly truncates data.
> 
> Perhaps if it were an optimization it could be implemented, but the 
> result of an optimization cannot change the validity of the code...
> 
> In other words, it couldn't be a compiler feature, it would have to be 
> part of the spec, which would mean all compilers must implement it.
> 
> BTW, I think cast is a perfect requirement here -- you are saying, yes I 
> know the risks and I'm casting anyways.
> 
> -Steve
He's saying the cast shouldn't be required, as the code entails that n 
will fit into a ubyte without loss of information.

Perhaps it's too much to ask.  I'm not sure.  I don't think he's sure. 
But if he doesn't ask, he won't find out.  (And it sure would be nice to 
avoid casts in situations analogous to that.)