On 06/27/12 17:38, Jonathan M Davis wrote: > On Wednesday, June 27, 2012 13:33:10 Timon Gehr wrote: >> On 06/27/2012 01:12 PM, kenji hara wrote: >>> 2012/6/27 Timon Gehr<[email protected]>: >>>> On 06/27/2012 07:27 AM, kenji hara wrote: >>>>> 2012/6/27 Jonathan M Davis<[email protected]>: >>>>>> 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-oeFVk6BG >>>>> [email protected] >>>>> >>>>> 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. > > Considering that if you said that a parameter is auto ref, you're basically > saying that it's being passed by value except that you'd like the compiler to > avoid the copy if it can, I don't see why it's restrictive at all to make
That's not what auto-ref does. We already had this discussion. auto-ref lets you eg wrap other ref-taking functions; it matters for things like templates and variadics, where ParameterTypeTuple can't be used. You can also check if an argument was passed by reference with traits(isRef) and handle it differently. artur
