Bug 16395 – auto return on override

Status
NEW
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2016-08-16T09:19:02Z
Last change time
2024-12-13T18:49:29Z
Keywords
spec
Assigned to
No Owner
Creator
Lodovico Giaretta
Moved to GitHub: dmd#19170 →

Comments

Comment #0 by lodovico — 2016-08-16T09:19:02Z
Currently DMD does not allow returning auto when overriding a function. Consider this case: =========================================== interface Foo { /* some methods */ } interface Bar { Foo getFoo(); } class BarImpl: Bar { override auto getFoo() { class FooImpl: Foo { // implementation of Foo ... // ... plus range methods } } } =========================================== Currently I have two options: 1) remove auto and return Foo instead; this way the user cannot use the range interface of FooImpl, because it receives a Foo 2) put FooImpl outside the function and return FooImpl; this way all functionality is correct, but it's not optimal as I have to put FooImpl outside the only function that uses it (which looks weird), plus FooImpl cannot implicitly access the getFoo context. This is not a essential enhancement, I don't know if it is feasible to implement it, but it would make the language features more orthogonal, allowing the use of overriding with return type inference and voldemort types.
Comment #1 by greeenify — 2016-08-16T09:48:23Z
> Currently I have two options: 3) use structs (they are usually used for ranges anyways). With alias this and mixins you can get a pretty decent inheritance, but of course I don't know your code ;-)
Comment #2 by lodovico — 2016-08-16T10:05:50Z
(In reply to greenify from comment #1) > > Currently I have two options: > > 3) use structs (they are usually used for ranges anyways). With alias this > and mixins you can get a pretty decent inheritance, but of course I don't > know your code ;-) True in general, but not really an option for my code (I need a certain amount of runtime polymorphism). Regardless of my example, which I solved with option 2, the question of this issue is "is this feasible to implement? If it is, why not have it? If it's not, fair enough."
Comment #3 by greeenify — 2016-08-16T10:15:37Z
> True in general, but not really an option for my code (I need a certain amount of runtime polymorphism). I thought so :/ > Regardless of my example, which I solved with option 2, the question of this issue is "is this feasible to implement? If it is, why not have it? If it's not, fair enough." I do agree that it's a bug / missing feature. If you want to get" dirty" yourself, I can highly recommend Walter's video from Dconf16
Comment #4 by robert.schadek — 2024-12-13T18:49:29Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/19170 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB