www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Inferred return types

reply Jacob Carlborg <doob me.com> writes:
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
Jun 29 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jun 29 2012
parent Jacob Carlborg <doob me.com> writes:
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
Jun 29 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Jun 29 2012
prev sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
 class Foo
 {
      auto foo ()
      {
          return "Foo";
      }
 }

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

But nonetheless covariance checking should be performed after inference.
Jun 29 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-06-30 01:25, Martin Nowak wrote:
 class Foo
 {
 auto foo ()
 {
 return "Foo";
 }
 }

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

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
Jun 30 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
 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 :)

Jul 12 2012