On Tuesday, December 25, 2012 11:14:40 Namespace wrote:
> > What does this generate?
> > 
> > auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S
> > d) { ... }
> > 
> > 16 different functions, one for each combination? Sounds like a bad idea.
> 
> In my opinion, this should produce only two functions:
> #1: auto foo(ref S a, ref S b, ref S c, ref S d) { ... }
> #2: auto foo(S a, S b, S c, S d) { ... }

So, you'd take the performance hit of copying all of your function arguments simply because one of them was an rvalue?

No. I think that Peter's point shows exactly why this is a bad idea.

However, creating only one version of the function which takes all refs and specifcally creating variables underneath the hood for any rvalues so that they can be passed to the function still seems like it could work.

- Jonathan M Davis

On Tuesday, December 25, 2012 11:12:43 Jens Mueller wrote:
> Jonathan M Davis wrote:
> > On Tuesday, December 25, 2012 01:56:42 Peter Alexander wrote:
> > > On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
> > > 
> > > wrote:
> > > > Why can't we simply make auto ref work with non-templated
> > > > functions by making
> > > > it automatically generate both the ref and non-ref versions?
> > > > 
> > > > [snip]
> > > > 
> > > > What problems does this cause? Why haven't we just done this already?
> > > 
> > > What does this generate?
> > > 
> > > auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S d)
> > > { ... }
> > > 
> > > 16 different functions, one for each combination? Sounds like a bad idea.
> > 
> > Excellent point.
> 
> I'm not sure but doesn't the compiler only create such a function when
> it is called.
> Still it may be confusing but it's similar to a function template. But
> here it's a template regarding passing convention.

If it were a template, sure. But the whole point is that we need a solution which _isn't_ a template, which in this case would mean generating every possible combination regardless of whether they were used or not. So, I think that Peter has shown why that particular approach is untenable.

- Jonathan M Davis

Jonathan M Davis wrote:
> On Tuesday, December 25, 2012 11:12:43 Jens Mueller wrote:
> > Jonathan M Davis wrote:
> > > On Tuesday, December 25, 2012 01:56:42 Peter Alexander wrote:
> > > > On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis
> > > > 
> > > > wrote:
> > > > > Why can't we simply make auto ref work with non-templated
> > > > > functions by making
> > > > > it automatically generate both the ref and non-ref versions?
> > > > > 
> > > > > [snip]
> > > > > 
> > > > > What problems does this cause? Why haven't we just done this already?
> > > > 
> > > > What does this generate?
> > > > 
> > > > auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S d)
> > > > { ... }
> > > > 
> > > > 16 different functions, one for each combination? Sounds like a bad idea.
> > > 
> > > Excellent point.
> > 
> > I'm not sure but doesn't the compiler only create such a function when
> > it is called.
> > Still it may be confusing but it's similar to a function template. But
> > here it's a template regarding passing convention.
> 
> If it were a template, sure. But the whole point is that we need a solution which _isn't_ a template, which in this case would mean generating every possible combination regardless of whether they were used or not. So, I think that Peter has shown why that particular approach is untenable.

And the solution needs to be non-template based because it needs to work with classes? Is that the only reason?

Jens

On Tuesday, December 25, 2012 11:44:45 Jens Mueller wrote:
> And the solution needs to be non-template based because it needs to work with classes? Is that the only reason?

That and if it's not non-templated, it's impossible to have auto ref functions which hide their implementation for those who need to use .di files to hide the implementation. It also might also be necessary if you need to be able to guarantee that the function exists. Basically, any situation where you can't use a template or where it's undesirable to use a template, the current auto ref doesn't work. But the big one is classes, as templated functions can't be virtual. Without a non-templated solution, virtual functions will never be able to do the equivalent of C++'s const& or anything like it, meaning that they'll incur overhead due to unnecessary copies in many cases.

- Jonathan M Davis

On 12/25/12 12:34 AM, Zhenya wrote:
> On Tuesday, 25 December 2012 at 01:40:16 UTC, Peter Alexander wrote:
>> On Tuesday, 25 December 2012 at 00:56:44 UTC, Peter Alexander wrote:
>>> On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis wrote:
>>>> And if that doesn't work, can we simply make it so that the compiler
>>>> automatically creates a variable when you pass an rvalue to a
>>>> non-templated
>>>> auto ref function?
>>>
>>> I don't see any problems with this, but I admittedly haven't thought
>>> too much about it.
>>
>> If there are no problems with this way, then what I want to know is
>> why the template version of auto ref wasn't implemented this way. The
>> way auto ref is currently implemented for templates is a bit of a mess.
> Maybe it's difficult to generate both versions because for the function
> like this
>
> void foo(auto ref S s1,auto ref S s2,...,auto ref s10)
>
> compiler should generate 2^10 versions of function foo.

The compiler will only generate as many versions as there are compatible calls.

Andrei

On 12/25/12 5:36 AM, Jonathan M Davis wrote:
> On Tuesday, December 25, 2012 11:14:40 Namespace wrote:
>>> What does this generate?
>>>
>>> auto foo(auto ref S a, auto ref S b, auto ref S c, auto ref S
>>> d) { ... }
>>>
>>> 16 different functions, one for each combination? Sounds like a
>>> bad idea.
>>
>> In my opinion, this should produce only two functions:
>> #1: auto foo(ref S a, ref S b, ref S c, ref S d) { ... }
>> #2: auto foo(S a, S b, S c, S d) { ... }
>
> So, you'd take the performance hit of copying all of your function arguments
> simply because one of them was an rvalue?
>
> No. I think that Peter's point shows exactly why this is a bad idea.
>
> However, creating only one version of the function which takes all refs and
> specifcally creating variables underneath the hood for any rvalues so that
> they can be passed to the function still seems like it could work.

Yes, that does work and is easy to implement.

Andrei

On Tuesday, 25 December 2012 at 14:09:13 UTC, Andrei Alexandrescu wrote:
> On 12/25/12 12:34 AM, Zhenya wrote:
>> On Tuesday, 25 December 2012 at 01:40:16 UTC, Peter Alexander wrote:
>>> On Tuesday, 25 December 2012 at 00:56:44 UTC, Peter Alexander wrote:
>>>> On Monday, 24 December 2012 at 17:40:54 UTC, Jonathan M Davis wrote:
>>>>> And if that doesn't work, can we simply make it so that the compiler
>>>>> automatically creates a variable when you pass an rvalue to a
>>>>> non-templated
>>>>> auto ref function?
>>>>
>>>> I don't see any problems with this, but I admittedly haven't thought
>>>> too much about it.
>>>
>>> If there are no problems with this way, then what I want to know is
>>> why the template version of auto ref wasn't implemented this way. The
>>> way auto ref is currently implemented for templates is a bit of a mess.
>> Maybe it's difficult to generate both versions because for the function
>> like this
>>
>> void foo(auto ref S s1,auto ref S s2,...,auto ref s10)
>>
>> compiler should generate 2^10 versions of function foo.
>
> The compiler will only generate as many versions as there are compatible calls.

If it were a template. Jonathan's (first) proposal is that they are all generated eagerly, so that they can be used as virtual functions (among other things). Generating them lazily like template defeats the purpose of his proposal (to do that, just use templates!)

The first proposal is a dead end. I think his second proposal is more interesting, so I will repeat it here:

"Can we simply make it so that the compiler automatically creates a variable when you pass an rvalue to a non-templated auto ref function?"

So non-template auto ref parameters are just like ref parameters, except they will automatically convert rvalues to lvalues on call by creating a local variable. Normal ref parameters will still need lvalues.

On Tuesday, 25 December 2012 at 14:11:14 UTC, Andrei Alexandrescu wrote:
> On 12/25/12 5:36 AM, Jonathan M Davis wrote:
>> However, creating only one version of the function which takes all refs and
>> specifcally creating variables underneath the hood for any rvalues so that
>> they can be passed to the function still seems like it could work.
>
> Yes, that does work and is easy to implement.

Is there any reason this hasn't been implemented? And why aren't template auto ref functions implemented like that? It would be a bit of a shame if auto ref in template functions works differently to auto ref in non-template function.

12/25/2012 6:15 PM, Peter Alexander пишет:
> On Tuesday, 25 December 2012 at 14:09:13 UTC, Andrei Alexandrescu wrote:
[snip]
>>>
>>> void foo(auto ref S s1,auto ref S s2,...,auto ref s10)
>>>
>>> compiler should generate 2^10 versions of function foo.
>>
>> The compiler will only generate as many versions as there are
>> compatible calls.
>
> If it were a template. Jonathan's (first) proposal is that they are all
> generated eagerly, so that they can be used as virtual functions (among
> other things). Generating them lazily like template defeats the purpose
> of his proposal (to do that, just use templates!)
>
> The first proposal is a dead end. I think his second proposal is more
> interesting, so I will repeat it here:
>
> "Can we simply make it so that the compiler automatically creates a
> variable when you pass an rvalue to a non-templated auto ref function?"
>
> So non-template auto ref parameters are just like ref parameters, except
> they will automatically convert rvalues to lvalues on call by creating a
> local variable. Normal ref parameters will still need lvalues.

+1
I think that was pretty much the conclusion of the last ref-to-rvalue thread. Just make sure proper scoping rules are followed.


-- 
Dmitry Olshansky

On 2012-12-25 15:11, Andrei Alexandrescu wrote:

> Yes, that does work and is easy to implement.

That's also what one needs to do now.

-- 
/Jacob Carlborg