www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Can we make auto return type inference a little more lax?

reply Andrej Mitrovic <none none.none> writes:
auto foo()
{
    if (1)
    {
        return [0, 0];
    }
    else
    {
        size_t one;
        size_t two;
        
        return [one, two];
    }
}

void main(){ }

Error: mismatched function return type inference of
uint[] and int[]

Surely the compiler can figure out a common type for these two when literals
are involved.
May 16 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-05-16 20:40, Andrej Mitrovic wrote:

 auto foo()
 {
     if (1)
     {
         return [0, 0];
     }
     else
     {
         size_t one;
         size_t two;
 
         return [one, two];
     }
 }
 
 void main(){ }
 
 Error: mismatched function return type inference of
 uint[] and int[]
 
 Surely the compiler can figure out a common type for these two when
 literals are involved.


I'm sure that auto return types are a tricky thing. The compiler also tends to 
have trouble when deducing the proper type for array literals. It's probably a 
similar problem. I believe that the compiler is supposed to take the common 
type but that it currently takes the last type in the literal as the element 
type of the array. auto return types probably have similar problems. In this 
case, it appears to be determining the types of each return value individually 
rather than collectively, and 0 defaults to int. Hence the failure. A cast 
will fix the problem. Still, it would be nice if the compiler were able to 
correctly determine that [0, 0] could be size_t[]. Open a bug report on it. It 
may or may not get fixed, and there's bound to be a limit to how smart the 
type inference can be, but Walter may very well look at improving it so that 
this works. It doesn't hurt to ask.

- Jonathan M Davis
May 16 2011
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Yeah it's low priority, but nice to have.

Note that there's a similar issue with tuples. However since tuples
are a library type and not first-class citizens (when it comes to
return types that is), the compiler probably won't be able to figure
out a common type.

What I mean is this:

auto foo()
{
   if (1)
   {
       tuple(0, 0);
   }
   else
   {
       size_t one;
       size_t two;

       tuple(one, two);
   }
}

I don't think the compiler can figure that one out unless tuples
become a standard language feature, not a library one. But maybe I'm
wrong.
May 16 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:


 I don't think the compiler can figure that one out unless tuples
 become a standard language feature, not a library one. But maybe I'm
 wrong.


Turning tuples into a a _partial_ language feature will be a good thing [TM]
for D. Tuples are useful in many situations, and they are easy to use.

Bye,
bearophile
May 17 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-05-16 21:31, Andrej Mitrovic wrote:

 Yeah it's low priority, but nice to have.
 
 Note that there's a similar issue with tuples. However since tuples
 are a library type and not first-class citizens (when it comes to
 return types that is), the compiler probably won't be able to figure
 out a common type.
 
 What I mean is this:
 
 auto foo()
 {
    if (1)
    {
        tuple(0, 0);
    }
    else
    {
        size_t one;
        size_t two;
 
        tuple(one, two);
    }
 }
 
 I don't think the compiler can figure that one out unless tuples
 become a standard language feature, not a library one. But maybe I'm
 wrong.


I'm sure that the compiler could be made to do it, but it would likely be very 
hacky to do so. It would have to realize that treating 0 as size_t for both 
arguments to tuple(0, 0) would result in the type Tuple!(size_t, size_t) which 
would be compatible with what's generated by tuple(one, two). I'm sure that it 
could be done without understanding anything about tuples specifically. It 
would just have to better understand templates. But it would likely be very 
complicated to implement for a pretty small gain, and there's a good chance 
that it would require a major redesign of that portion of the compiler. So, I 
wouldn't expect that to ever work. It should technically be possible, however.

- Jonathan M Davis
May 16 2011
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 17/05/2011 04:40, Andrej Mitrovic wrote:

 auto foo()
 {
      if (1)
      {
          return [0, 0];
      }
      else
      {
          size_t one;
          size_t two;

          return [one, two];
      }
 }

 void main(){ }

 Error: mismatched function return type inference of
 uint[] and int[]

 Surely the compiler can figure out a common type for these two when literals
are involved.


I haven't tested, but make the first array [0u, 0u], that should work, 
as a work around. Make a bug report for this (maybe a patch if you feel 
up to it? :D).

-- 
Robert
http://octarineparrot.com/
May 17 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Bug is in bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=6022

I'm not a compiler writer though, sorry. :)
May 17 2011