View mode: basic / threaded / horizontal-split · Log in · Help
June 29, 2012
Inferred return types
I just noticed that the return type of a function can be inferred 
without using a storage class:


@property foo ()
{
    return "foo";
}

void main ()
{
    string str = foo;
}

Is that supposed to work? The specification says:

"If it does not already have a storage class, use the auto storage class."

But @property is not a storage class. It seems I can put most of the 
attributes there instead of @property, both those with and without a @.

Second, it seems it's not possible to override a method with an inferred 
return type, as the example below shows:

class Foo
{
    auto foo ()
    {
        return "Foo";
    }
}

class Bar : Foo
{
    auto foo ()
    {
        return "Bar";
    }
}

void main ()
{
    Foo f = new Bar;
    writeln(f.foo());
}

Results in:

Error: function main.Bar.foo of type () overrides but is not covariant 
with main.Foo.foo of type ()

-- 
/Jacob Carlborg
June 29, 2012
Re: Inferred return types
On 06/29/2012 09:17 PM, Jacob Carlborg wrote:
> I just noticed that the return type of a function can be inferred
> without using a storage class:
>
>
> @property foo ()
> {
>      return "foo";
> }
>
> void main ()
> {
>      string str = foo;
> }
>
> Is that supposed to work?

Yes.

> The specification says:
>
> "If it does not already have a storage class, use the auto storage class."
>
> But @property is not a storage class. It seems I can put most of the
> attributes there instead of @property, both those with and without a @.
>

The spec (and the implementation as well) considers them to be storage
classes. I think the term 'storage class' should be retired.


> Second, it seems it's not possible to override a method with an inferred
> return type, as the example below shows:
>
> class Foo
> {
>      auto foo ()
>      {
>          return "Foo";
>      }
> }
>
> class Bar : Foo
> {
>      auto foo ()
>      {
>          return "Bar";
>      }
> }
>
> void main ()
> {
>      Foo f = new Bar;
>      writeln(f.foo());
> }
>
> Results in:
>
> Error: function main.Bar.foo of type () overrides but is not covariant
> with main.Foo.foo of type ()
>
> --
> /Jacob Carlborg

This is a bug I have run into as well, but I have missed to report it.
June 29, 2012
Re: Inferred return types
Jacob Carlborg:

> Is that supposed to work?

If the D specs don't agree, then in this case I think the D specs 
need to be modified.



> Second, it seems it's not possible to override a method with an 
> inferred return type,

This seems a bug report fit for Bugzilla:


class Foo {
    string foo() {
        return "Foo.foo";
    }
}
class Bar : Foo {
    override /*string*/ foo() { // compiles un-commenting string
        return "Bar.foo";
    }
}
void main() {}


Bye,
bearophile
June 29, 2012
Re: Inferred return types
On 2012-06-29 21:25, Timon Gehr wrote:

> This is a bug I have run into as well, but I have missed to report it.

Reported: http://d.puremagic.com/issues/show_bug.cgi?id=8318

-- 
/Jacob Carlborg
June 29, 2012
Re: Inferred return types
> class Foo
> {
>      auto foo ()
>      {
>          return "Foo";
>      }
> }
>
> class Bar : Foo
> {
>      auto foo ()
>      {
>          return "Bar";
>      }
> }
>
Ouch, what a terrible idea to base a class hierachy on inference.
But nonetheless covariance checking should be performed after inference.
June 30, 2012
Re: Inferred return types
On 2012-06-30 01:25, Martin Nowak wrote:
>> class Foo
>> {
>> auto foo ()
>> {
>> return "Foo";
>> }
>> }
>>
>> class Bar : Foo
>> {
>> auto foo ()
>> {
>> return "Bar";
>> }
>> }
>>
> Ouch, what a terrible idea to base a class hierachy on inference.
> But nonetheless covariance checking should be performed after inference.

I actually found the bug by mistake. I was going to override a method in 
a subclass and got the error. The strange thing is that I had copied the 
method from the super class and it didn't work anyway. Then I saw, in 
the super class, that I didn't have a return type on the method. I had 
just missed declaring a return type, the intention was not to use type 
inference. I guess I use Ruby too much :)

-- 
/Jacob Carlborg
July 12, 2012
Re: Inferred return types
> I actually found the bug by mistake. I was going to override a method in  
> a subclass and got the error. The strange thing is that I had copied the  
> method from the super class and it didn't work anyway. Then I saw, in  
> the super class, that I didn't have a return type on the method. I had  
> just missed declaring a return type, the intention was not to use type  
> inference. I guess I use Ruby too much :)
>
https://github.com/D-Programming-Language/dmd/blob/master/src/parse.c#L2598
Top | Discussion index | About this forum | D home