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

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.

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

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

> 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.

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

> 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