Can we make auto return type inference a little more lax?

[Jonathan M Davis]

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