Re: Can we make auto return type inference a little more lax?
Bug is in bugzilla: http://d.puremagic.com/issues/show_bug.cgi?id=6022 I'm not a compiler writer though, sorry. :)
Re: Can we make auto return type inference a little more lax?
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/
Re: Can we make auto return type inference a little more lax?
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
Re: Can we make auto return type inference a little more lax?
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
Re: Can we make auto return type inference a little more lax?
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.
Re: Can we make auto return type inference a little more lax?
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
Can we make auto return type inference a little more lax?
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.
