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
