digitalmars.D - Inferred return types
- Jacob Carlborg (40/40) Jun 29 2012 I just noticed that the return type of a function can be inferred
- Timon Gehr (5/46) Jun 29 2012 The spec (and the implementation as well) considers them to be storage
- Jacob Carlborg (4/5) Jun 29 2012 Reported: http://d.puremagic.com/issues/show_bug.cgi?id=8318
- bearophile (17/20) Jun 29 2012 If the D specs don't agree, then in this case I think the D specs
- Martin Nowak (2/16) Jun 29 2012 Ouch, what a terrible idea to base a class hierachy on inference.
- Jacob Carlborg (9/27) Jun 30 2012 I actually found the bug by mistake. I was going to override a method in...
- Martin Nowak (1/7) Jul 12 2012 https://github.com/D-Programming-Language/dmd/blob/master/src/parse.c#L2...
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
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 CarlborgThis is a bug I have run into as well, but I have missed to report it.
Jun 29 2012
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
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
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
On 2012-06-30 01:25, Martin Nowak wrote: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 Carlborgclass 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 30 2012
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