'Auto can only be used for template function arguments' what?

[Timon Gehr]

On 06/27/2012 01:12 PM, kenji hara wrote:
> 2012/6/27 Timon Gehr<timon.gehr at gmx.ch>:
>> On 06/27/2012 07:27 AM, kenji hara wrote:
>>>
>>> 2012/6/27 Jonathan M Davis<jmdavisProg at gmx.com>:
>>>>
>>>> On Wednesday, June 27, 2012 07:02:28 Mehrdad wrote:
>>>>
>>>>> On Wednesday, 27 June 2012 at 04:26:08 UTC, Jonathan M Davis
>>>>>
>>>>> wrote:
>>>>>>
>>>>>> And how would that work? auto ref duplicates the function. If
>>>>>> you pass it an lvalue, then it generates a ref version.
>>>>>
>>>>>
>>>>> Two solutions:
>>>>>
>>>>> - Turn 'auto ref' into 'ref', but simply have the compiler
>>>>> generate a copy for the caller if he wants to pass by value?
>>>>
>>>>
>>>> That at least sounds like it would work. Walter may have a reason why it
>>>> doesn't though, since he's the one that said that he didn't think that it
>>>> was
>>>> possible. Maybe he just didn't think of it, or maybe it causes some other
>>>> problem that I can't think of.
>>>
>>>
>>> After considering about 'auto ref', I was concluded that is an
>>> inconsistency of current language spec and we cannot fix it correctly.
>>>
>>> http://d.puremagic.com/issues/show_bug.cgi?id=8204
>>>
>>> Therefore, I have created a thread to suggest new 'auto ref' recently.
>>>
>>> http://forum.dlang.org/thread/CAFDvkcvf6G8Mc01Tds6ydXqCZbfp1q-a-oeFVk6BGEtwCiUAqg@mail.gmail.com
>>>
>>> Kenji Hara
>>>
>>>
>>
>> How does it deal with this case?
>>
>> auto ref id(auto ref arg){ return arg; }
>
> In this case, arg might bind rvalue allocated in the caller of id, so
> returning it with ref should be rejected statically.
> But it is yet not implemented in pull#1019.
>
> Kenji Hara

This is a quite severe limitation compared to how auto ref works today.
As the return ref-ness is inferred and therefore the source code must
be available, wouldn't it be a better option to decide
lvalue/rvalue-ness at the call site? The compiler would just have to
examine the first return statement in the function body.