On Thursday, 21 August 2014 at 05:24:13 UTC, Artur Skawina via
Digitalmars-d wrote:
While D's `ref` is a hack, it's /already/ part of the function
type/signature.
The return type of a function is /already/ (ie in the D
dialects supported
by recent frontend releases) determined from *all* returned
expression.
What would be the advantage of propagating/inferring only the
type, but not
the lvalueness?...
I think I understand the issue better now.
D doesn't always deduce a common return type, e.g.
class A {}
class B {}
auto foo() {
return new A();
return new B();
}
This fails to compile with "mismatched function return type",
even though it could easily return Object. However, it seems to
do some deduction of sorts with integral types, e.g. this deduces
to return double.
auto foo() {
return 0;
return 0.0;
return 0UL;
}
I'm not sure what logic it is using to do common type deductions.
I haven't investigated fully.
The problem comes with recursion, which we don't handle at the
moment for auto or auto ref functions, but handling that becomes
much easier when you just assume the return type is the return
type from the first return statement, so I see the value in the
described approach.
