Bug 8307 – inconsistent treatment of auto functions
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dlang.org
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-06-27T04:56:00Z
Last change time
2015-02-18T03:40:23Z
Keywords
pull, spec
Assigned to
nobody
Creator
timon.gehr
Comments
Comment #0 by timon.gehr — 2012-06-27T04:56:58Z
function.html states:
"Auto Functions
Auto functions have their return type inferred from any ReturnStatements in the function body.
An auto function is declared without a return type. If it does not already have a storage class, use the auto storage class.
If there are multiple ReturnStatements, the types of them must match exactly. If there are no ReturnStatements, the return type is inferred to be void. "
DMD sez:
auto foo(){ return 0; return 0.0; } // ok
auto bar(int x){ if(x==0) return 0; return bar(x-1)+1; } // error
The compiler, the documentation or both need to be fixed.
Comment #1 by yebblies — 2013-11-26T08:05:17Z
Spec bug, setting component.
Comment #2 by andrej.mitrovich — 2014-04-23T00:00:42Z
> auto foo(){ return 0; return 0.0; } // ok
Warning: statement is not reachable
> auto bar(int x){ if(x==0) return 0; return bar(x-1)+1; } // error
Error: forward reference to bar
The spec seems correct afaict, unless I'm missing something.
Comment #3 by timon.gehr — 2014-04-23T00:58:43Z
(In reply to Andrej Mitrovic from comment #2)
>
> The spec seems correct afaict,
???
> unless I'm missing something.
In 'foo' the types of the two return expressions do not 'match exactly', yet it is accepted. In 'bar' according to the spec the return type is settled after the first return statement, hence there would _not_ be a circular dependency.
Comment #4 by andrej.mitrovich — 2014-04-23T15:08:35Z
(In reply to timon.gehr from comment #3)
> In 'foo' the types of the two return expressions do not 'match exactly', yet
> it is accepted.
There's an error with -w though, so it's caught one way or the other. Although maybe we're just lucky here.
> In 'bar' according to the spec the return type is settled
> after the first return statement, hence there would _not_ be a circular
> dependency.
Ah, ok then.