auto ref deduction and common type deduction inconsistency

[Peter Alexander via Digitalmars-d]

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.