On Fri, 17 Jul 2009 08:08:23 -0400, Don <nospam@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

Steven Schveighoffer wrote:
> On Fri, 17 Jul 2009 08:08:23 -0400, Don <nospam@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;
}

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

> Steven Schveighoffer wrote:
>> On Fri, 17 Jul 2009 08:08:23 -0400, Don <nospam@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

Steven Schveighoffer:
> 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)

It doesn't compile (DMD v2.031):
temp.d(5): Error: incompatible types for ((255) ? (n)): 'int' and 'temp.C'

Bye,
bearophile