On Monday, 22 June 2015 at 20:56:12 UTC, Jonathan M Davis wrote:
> won't mutate the argument, but if you allow it with ref in general, then you stand no chance of being able to look at a function signature and deduce whether the function intends to mutate an argument or not.
>
> - Jonathan M Davis

It's no worse than auto ref. It's only by convention that auto ref functions doesn't mutate, at least I follow that convention, but when looking at someone else's function, all bets are off.

On Monday, 22 June 2015 at 04:11:41 UTC, Andrei Alexandrescu wrote:
> Walter and I discussed what auto ref for templates should look like and reached the conclusion that an approach based on lowering would be best. I added a proposed lowering to https://github.com/D-Programming-Language/dmd/pull/4717.

`For example, consider the declaration:`

ref int fun(auto ref int x);

`That should lower to:`

ref int fun(int' x);   /* or */   ref int fun('int x);

On 06/22/2015 06:11 AM, Andrei Alexandrescu wrote:
> Walter and I discussed what auto ref for templates should look like and
> reached the conclusion that an approach based on lowering would be best.
> I added a proposed lowering to
> https://github.com/D-Programming-Language/dmd/pull/4717.
>
> Andrei

"@WalterBright auto ref for templates and non-templates do different things by necessity. ..."

The proposed lowering also works for template functions.

"... This is not an issue."

Yes it is. Walter is right.

On Monday, 22 June 2015 at 18:34:37 UTC, Namespace wrote:
> On Monday, 22 June 2015 at 18:03:43 UTC, Temtaime wrote:
>> I see no reasons why « ref in » is bad. Maybe someone explain ?
>> It's also natural for those who came from C++.
>> In C++ there's no problem with const&, so why they will be in D?
>
> Because const is transitive in D and therefore more restrictive.

That's not a reason. It's just an additional restriction imposed by D and only prevents you from using the proposed `in ref T`/`const auto ref T` *shudder* equivalents if const-transitiveness would be violated. In my day-to-day C++ work, I almost never have to do that.

C++ "simply" ;) relies on the callee not escaping rvalue references bound to `const T&`. D's `(const/immutable) ref` only allows lvalue arguments. It simply says: 'Hey stupid, don't give me an rvalue reference, it might escape!' So to circumvent this common problem, you'll currently have to either (a) create an `auto ref` template or (b) declare a new variable, potentially having to introduce a new scope.

Is it ugly?
(a) Leads to code bloat, but provides for in-place parameter construction (and no indirections) for rvalue arguments of suited types.
(b) Definitely ugly.

Is it safe now?
(a) Ideally, the rvalue argument was in-place constructed in the function parameters stack. Noone but you, the dev, prevents the callee from escaping a reference to the parameter though.
(b) Well, the code is more verbose and emphasizes the original function argument expression. But it's obviously still all your responsibility to take care of proper lifetime for escaping references. Just declaring the variable right before the function call isn't safer than passing the rvalue reference directly.

So none of this really solves the underlying problem. One solution consists in classifying function parameter references as non-escaping ones (proposed `scope ref`/non-template `auto ref` accepting rvalues too, to be verified by compiler) and escaping ones (`ref`), the bad ones to watch out for. I'd like having to syntactically annotate an lvalue argument passed by non-scope ref, analog to C#, i.e., `foo(ref argument)`, to more easily catch the eye.

On 6/22/15 3:06 PM, Timon Gehr wrote:
> On 06/22/2015 06:11 AM, Andrei Alexandrescu wrote:
>> Walter and I discussed what auto ref for templates should look like and
>> reached the conclusion that an approach based on lowering would be best.
>> I added a proposed lowering to
>> https://github.com/D-Programming-Language/dmd/pull/4717.
>>
>> Andrei
>
> "@WalterBright auto ref for templates and non-templates do different
> things by necessity. ..."
>
> The proposed lowering also works for template functions.
>
> "... This is not an issue."
>
> Yes it is. Walter is right.

For templates, auto ref generates two copies of the function. Inside, which was generated can be interrogated by using is(param == ref). For non-templates, only one copy of the function is generated. Using is(param == ref) inside should be an error.

The two mechanisms bear many similarities and some differences, too.


Andrei

On 06/23/2015 12:18 AM, kinke wrote:
>>> In C++ there's no problem with const&, so why they will be in D?
>>
>> Because const is transitive in D and therefore more restrictive.
>
> That's not a reason.

Yes it is.

> It's just an additional restriction imposed by D and only prevents
> you from using the proposed `in ref T`/`const auto ref T` *shudder*
> equivalents if const-transitiveness would be violated. In my
> day-to-day C++ work, I almost never have to do that.

Note "almost".

On 06/23/2015 12:40 AM, Andrei Alexandrescu wrote:
> On 6/22/15 3:06 PM, Timon Gehr wrote:
>> On 06/22/2015 06:11 AM, Andrei Alexandrescu wrote:
>>> Walter and I discussed what auto ref for templates should look like and
>>> reached the conclusion that an approach based on lowering would be best.
>>> I added a proposed lowering to
>>> https://github.com/D-Programming-Language/dmd/pull/4717.
>>>
>>> Andrei
>>
>> "@WalterBright auto ref for templates and non-templates do different
>> things by necessity. ..."
>>
>> The proposed lowering also works for template functions.
>>
>> "... This is not an issue."
>>
>> Yes it is. Walter is right.
>
> For templates, auto ref generates two copies of the function. Inside,
> which was generated can be interrogated by using is(param == ref). For
> non-templates, only one copy of the function is generated. Using
> is(param == ref) inside should be an error.
>
> The two mechanisms bear many similarities and some differences, too.
> ...

There is no reason to prevent templates from using the mechanism that generates only one copy. The two mechanisms shouldn't share the same syntax, because then there is no way to tell them apart for template functions.

On Monday, 22 June 2015 at 23:04:14 UTC, Timon Gehr wrote:
> On 06/23/2015 12:18 AM, kinke wrote:
>>>> In C++ there's no problem with const&, so why they will be in D?
>>>
>>> Because const is transitive in D and therefore more restrictive.
>>
>> That's not a reason.
>
> Yes it is.
>
>> It's just an additional restriction imposed by D and only prevents
>> you from using the proposed `in ref T`/`const auto ref T` *shudder*
>> equivalents if const-transitiveness would be violated. In my
>> day-to-day C++ work, I almost never have to do that.
>
> Note "almost".

Ah, I remember you from another rvalue discussion some years ago. ;)
Care to share an example where transitive const is a problem apart from obvious lazily caching stuff? I don't think I've encountered any lately.

On 06/23/2015 01:27 AM, kinke wrote:
> On Monday, 22 June 2015 at 23:04:14 UTC, Timon Gehr wrote:
>> On 06/23/2015 12:18 AM, kinke wrote:
>>>>> In C++ there's no problem with const&, so why they will be in D?
>>>>
>>>> Because const is transitive in D and therefore more restrictive.
>>>
>>> That's not a reason.
>>
>> Yes it is.
>>
>>> It's just an additional restriction imposed by D and only prevents
>>> you from using the proposed `in ref T`/`const auto ref T` *shudder*
>>> equivalents if const-transitiveness would be violated. In my
>>> day-to-day C++ work, I almost never have to do that.
>>
>> Note "almost".
> ...
> Care to share an example where transitive const is a problem apart from
> obvious lazily caching stuff?

One obvious problem ought to be enough. Some of the remaining cases are obvious as well. Others are not. One way to avoid non-obvious issues is to keep language features orthogonal.

> I don't think I've encountered any lately.

The problems with transitive const to be encountered in day-to-day C++ work are few.

On Monday, 22 June 2015 at 04:11:41 UTC, Andrei Alexandrescu wrote:
> Walter and I discussed what auto ref for templates should look like and reached the conclusion that an approach based on lowering would be best. I added a proposed lowering to https://github.com/D-Programming-Language/dmd/pull/4717.
>
> Andrei

It seems to me that this may be an important target to seek:

auto foo(auto ref T bar) {}

Should be callable in the same manner

auto foo()(auto ref T bar) {}

is callable. That is to say it would be unfortunate if turning it into a template would cause different behaviors.

If nothing else, deviations should be well documented and explained.