auto ref deduction and common type deduction inconsistency

[deadalnix via Digitalmars-d]

On Tuesday, 19 August 2014 at 22:28:27 UTC, Peter Alexander wrote:
> Consider these two functions:
>
> auto ref foo(ref int x) {
>   if (condition) return x;
>   return 3;
> }
>
> auto ref bar(ref int x) {
>   return condition ? x : 3;
> }
>
> At a first glance, they appear to be equivalent, however foo is 
> a compile-time error "constant 3 is not an lvalue" while bar 
> compiles fine and returns an rvalue int.
>
> The  rule in the spec is "The lexically first ReturnStatement 
> determines the ref-ness of [an auto ref] function"
>
> Why is this? I think it would be more consistent and convenient 
> to be: "An auto ref function returns by ref if all return paths 
> return an lvalue, else it returns by value".
>
> Am I missing something? I don't see why foo should be rejected 
> at compile time when it can happily return by value.
>
> 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.