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";
      }
 }


Ouch, what a terrible idea to base a class hierachy on inference.
But nonetheless covariance checking should be performed after inference.
Jun 29 2012
parent reply 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";
 }
 }


 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
Jun 30 2012
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 :)


https://github.com/D-Programming-Language/dmd/blob/master/src/parse.c#L2598
Jul 12 2012