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