auto ref deduction and common type deduction inconsistency

[Artur Skawina via Digitalmars-d]

On 08/20/14 23:39, deadalnix via Digitalmars-d wrote:
> On Tuesday, 19 August 2014 at 22:28:27 UTC, Peter Alexander wrote:
>> It is especially problematic in generic code where you opportunistically want to return by ref when possible, e.g.:
>>
>> auto ref f(alias g, alias h)()
>> {
>>   if (condition)
>>     return g();
>>   return h();
>> }
>>
>> If g returns by ref while h returns by value then this fails to instantiate. It would be nice if it just returned by value (as return condition ? g() : h() would)
> 
> If I agree, you must understand that this increase wildly the cost of the analysis required to infer return type and/or refness.
> 
> It makes the compiler implementation *way* more complex and could increase the compilation cost a lot.
> 
> Consider that auto ref functions can happily call each others and you'll have to go through each of them as a graph, having set of possible return type and refness, aggregate these infos on a per function basis, removing cycles (so a function return type do not depend on itself).
> 
> This hack in the spec come handy, and, unless we can come up with a good implementation of a more general spec, I'd argue for it to stay there.

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?...

artur