On 06/27/2012 07:27 AM, kenji hara wrote:
> 2012/6/27 Jonathan M Davis<jmdavisProg@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; }

2012/6/27 Timon Gehr <timon.gehr@gmx.ch>:
> On 06/27/2012 07:27 AM, kenji hara wrote:
>>
>> 2012/6/27 Jonathan M Davis<jmdavisProg@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

On 06/27/2012 01:12 PM, kenji hara wrote:
> 2012/6/27 Timon Gehr<timon.gehr@gmx.ch>:
>> On 06/27/2012 07:27 AM, kenji hara wrote:
>>>
>>> 2012/6/27 Jonathan M Davis<jmdavisProg@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.

On 06/27/12 07:27, kenji hara wrote:
> 2012/6/27 Jonathan M Davis <jmdavisProg@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

Please do not remove useful functionality in order to fix unrelated problems. "auto ref" isn't perfect, but it works well for some cases. A new "override ref" could work like you describe.

artur

Artur Skawina:

> A new "override ref" could work like you describe.

Introducing yet more modifiers and complexity should be done only if they are very useful.

Bye,
bearophile

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<timon.gehr@gmx.ch>:
> >> On 06/27/2012 07:27 AM, kenji hara wrote:
> >>> 2012/6/27 Jonathan M Davis<jmdavisProg@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-oeFVk6BG EtwCiUAqg@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.

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 returning a ref to the parameter illegal. It would be like if you wanted to return a & to a const& parameter in C++, which would be a very bad idea.

- Jonathan M Davis

On Wednesday, June 27, 2012 16:39:12 Artur Skawina wrote:
> On 06/27/12 07:27, kenji hara wrote:
> > 2012/6/27 Jonathan M Davis <jmdavisProg@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-oeFVk6BGEt wCiUAqg@mail.gmail.com
> Please do not remove useful functionality in order to fix unrelated problems. "auto ref" isn't perfect, but it works well for some cases. A new "override ref" could work like you describe.

What functionality are you talking about? What would you lose?

- Jonathan M Davis

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<timon.gehr@gmx.ch>:
>>>> On 06/27/2012 07:27 AM, kenji hara wrote:
>>>>> 2012/6/27 Jonathan M Davis<jmdavisProg@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-oeFVk6BG EtwCiUAqg@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.
> 
> 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

On 06/27/12 18:04, Artur Skawina wrote:
> On 06/27/12 17:38, Jonathan M Davis wrote:
>> On Wednesday, June 27, 2012 13:33:10 Timon Gehr wrote:
>> 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

To clarify - /avoiding a copy/ is not the only, or even the main, use of this feature. Copy avoidance mostly matters for structs, and these cases should eventually be handled in a better way - but even when that will be done, auto-ref will still remain useful.

artur

On Wednesday, June 27, 2012 18:13:24 Artur Skawina wrote:
> On 06/27/12 18:04, Artur Skawina wrote:
> > On 06/27/12 17:38, Jonathan M Davis wrote:
> >> On Wednesday, June 27, 2012 13:33:10 Timon Gehr wrote:
> >> 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
> To clarify - /avoiding a copy/ is not the only, or even the main, use of this feature. Copy avoidance mostly matters for structs, and these cases should eventually be handled in a better way - but even when that will be done, auto-ref will still remain useful.

The _entire_ reason that auto ref on parameters was introduced in the first
place was to have something comparable to C++'s const& which took both
lvalues and rvalues efficiently without having to care which it was. That is the
purpose of the feature. That's it. It may be that you've found other uses for
it, but that's why it exists. The fact that it's implemented the way it is
with templates is entirely an artifact of Walter having misunderstand what
Andrei intended (which was for auto ref to somehow take both lvalues and
rvalues with a single function definition while avoiding copying the lvalues).

So, you may have an argument for why auto ref shouldn't be change, but if so, you're arguing for something that auto ref was never intended for.

- Jonathan M Davis