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

Jonathan M Davis jmdavisProg at gmx.com
Mon May 16 21:39:15 PDT 2011


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


More information about the Digitalmars-d-learn mailing list