rvalues -> ref (yup... again!)

[Timon Gehr]

On 24.03.2018 05:03, Manu wrote:
> On 23 March 2018 at 20:17, Timon Gehr via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 24.03.2018 02:16, Manu wrote:
>>>
>>> This is an interesting point, but I don't think it changes the balance
>>> in any way. Thinking of the majority of my anecdotal cases, I don't
>>> think it would be a problem.
>>> Something complex enough for const to be a problem likely doesn't
>>> conform to this pattern.
>>
>>
>> Why aim for "it often works", when we want "it always works"? Forcing const
>> upon people who want to pass rvalues by reference is just not good enough.
>> It is bad language design.
> 
> I think you need to re-read the whole thread, and understand what
> we're even talking about. ...

That will not be necessary. I wouldn't even have had to read it the 
first time. Those discussions always go the same way:

M: I wish we could pass rvalue arguments to ref parameters.
J: That would be terrible, as people would then pass rvalues as ref by 
accident and not see the mutation that the author of the function 
intended them to see.
M: Only do it for const ref parameters then.
T: No, this has nothing to do with const.

(M can be replaced by a variety of other letters; this is a somewhat 
common feature request.)

> Nobody wants to pass rvalues by mutable-ref... that's completely
> pointless, since it's an rvalue that will timeout immediately anyway.
> Passing by const-ref is perfectly acceptable.
> ...

Your temporary might have mutable indirections. Maybe you don't want to 
be forced to annotate your methods as const, limiting your future options.

> I suspect Jonathan's talking about classic D situations with const
> like, I might pass by const-ref, but then I can't call a getter that
> caches the result.
> That's a classic problem with D's const, and that's not on debate
> here. I don't think that has any impact on this proposal; people
> understand what const means in D, and that's no different here than
> anywhere else.
> ...

Your proposal _changes_ the meaning of const. I.e., "const does all it 
did previously and now it also allows rvalues to be passed to ref 
functions". This is bad, as one has little to do with the other, yet now 
you couple them. Programmers who want to pass rvalues as ref do not 
necessarily want to use D const on their objects.

> 
>> Also I think the point about documenting mutation intent is moot, as rvalues
>> can be receivers for method calls, which will _already_ pass an rvalue by
>> reference no matter whether it intends to mutate it or not. We can require
>> some special annotation for this behavior, but I'd be perfectly fine without
>> it.
> 
> I have no idea what this paragraph means... can you elaborate further
> what you're talking about?
> 

This works:

struct S{
     int x;
     void inc(){
         this.x++; // note: 'this' is passed by ref
     }
}

void main(){
     S().inc();
}

but this does not:

struct S{
     int x;
}
void inc(ref S self){
     self.x++; // note: 'self' is passed by ref
}

void main(){
     S().inc();
}

I.e. there is a special case where your rewrite is already applied. Note 
how "inc" cannot even be made const.

What I'm saying is that I don't really buy Jonathan's argument. 
Basically, you should just pass the correct arguments to functions, as 
you always need to do. If you cannot use the result of some mutation 
that you need to use, you will probably notice.


There are only three sensible ways to fix the problem:

1. Just allow rvalue arguments to bind to ref parameters. (My preferred 
solution, though it will make the overloading rules slightly more 
complicated.)

2. Add some _new_ annotation for ref parameters that signifies that you 
want the same treatment for them that the implicit 'this' reference 
gets. (A close second.)

3. Continue to require code bloat (auto ref) or manual boilerplate 
(overloads). (I'm not very fond of this option, but it does not require 
a language change.)