dmd 1.046 and 2.031 releases

[Steven Schveighoffer]

On Fri, 17 Jul 2009 09:46:11 -0400, Don <nospam at nospam.com> wrote:

> Steven Schveighoffer wrote:
>> On Fri, 17 Jul 2009 08:08:23 -0400, Don <nospam at nospam.com> wrote:
>>
>>> In this case, I think bearophile's right: it's just a problem with  
>>> range propagation of the ?: operator. I think the compiler should be  
>>> required to do the semantics analysis for single expressions. Not  
>>> more, not less.
>>  Why?  What is the benefit of keeping track of the range of integral  
>> variables inside an expression, to eliminate a cast?  I don't think  
>> it's worth it.  As far as I know, the ?: is the only expression where  
>> this can happen.  You will get cries of inconsistency when the compiler  
>> doesn't allow:
>>  ubyte foo(uint x)
>> {
>>   if(x < 256)
>>      return x;
>>   return 0;
>> }
>>  -Steve
> Already happens. This works:
>
> ubyte foo(uint n)
> {
>    return true ? 255 : n;
> }
>
> And this fails:
>
> ubyte boo(uint n)
> {
>    if (true) return 255;
>    else return n;
> }

Does that require range propogation?  That is, when the compiler sees:

return true ? 255

does it even look at the type or range of the other branch?

Does this compile:

class C {}

ubyte foo(C n)
{
   return true ? 255 : n;
}

(don't have the latest compiler installed yet, so I couldn't check it  
myself)

I think the situation is different because the compiler isn't forced to  
consider the other branch, it can be optimized out (I'm surprised it  
doesn't do that in the general if(true) case anyways, even with  
optimization turned off).

-Steve