headers
Jacob Carlborg | 29 Jun 2012 21:17

Inferred return types

I just noticed that the return type of a function can be inferred 
without using a storage class:

 <at> 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  <at> property is not a storage class. It seems I can put most of the 
attributes there instead of  <at> property, both those with and without a  <at> .

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";
     }
}
(Continue reading)

Permalink | Reply |
headers
Timon Gehr | 29 Jun 2012 21:25
Picon
Picon

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:
>
>
>  <at> 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  <at> property is not a storage class. It seems I can put most of the
> attributes there instead of  <at> property, both those with and without a  <at> .
>

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

Permalink | Reply |
headers
Jacob Carlborg | 29 Jun 2012 21:55

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
Permalink | Reply |
headers
bearophile | 29 Jun 2012 21:33
Picon

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
Permalink | Reply |
headers
Martin Nowak | 30 Jun 2012 01:25
Picon

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.
Permalink | Reply |
headers
Jacob Carlborg | 30 Jun 2012 13:00

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
(Continue reading)

Permalink | Reply |
headers
Martin Nowak | 12 Jul 2012 23:32
Picon

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
Permalink | Reply |

Gmane