The liabilities of binding rvalues to ref

Steven Schveighoffer schveiguy at yahoo.com
Fri May 10 06:15:19 PDT 2013


On Fri, 10 May 2013 00:44:08 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Thursday, May 09, 2013 22:33:09 Steven Schveighoffer wrote:
>> On Thu, 09 May 2013 22:10:22 -0400, Jonathan M Davis  
>> <jmdavisProg at gmx.com>
>> > That would be great except for UFCS. How would you designate the ref
>> > when it's
>> > the first argument? And I think that it's worse to have ref optional  
>> at
>> > the
>> > callsite than to not have it at all.
>>
>> 1. using UFCS is optional.  c[i].fix() works as well as fix(c[i]).
>
> That would be an option, but as I explain belong, I think that having  
> ref be
> optional at the call site is a bad idea.
>
>> 2. We could say UFCS has an implicit ref-at-callsite if needed, and will
>> not compile for rvalues.  If you think about it, 'this' is implicitly  
>> ref,
>> and UFCS is calling like the first argument is the 'this' reference.
>
> That would make using UFCS with ranges generally illegal, as most  
> range-based
> funtions do not have ref parameters, and you generally don't want them  
> to be
> passed by ref.

I misunderstood.  You would not need ref at callsite because it's  
optional.  So this actually is fine.  You don't need to do anything.

How would you prevent 'rvalue' ranges from going in?  Don't use UFCS, and  
put ref at callsite.

The problem with this whole rvalue/lvalue scheme is that rvalue and lvalue  
are not good terms to describe what we want.  Just because you can't  
assign to an rvalue doesn't mean you can't assign to a member of that  
rvalue, it could be a pointer.

> This has come up on the newsgroup before, and I really do think that  
> having it
> as optional is worse than not having it. If it's required, then when you  
> see
> that an argument is marked with ref, you know that the parameter is a ref
> parameter, and when you see an argument without ref, you know that the
> parameter is not a ref parameter. And the compiler enforces both, so you
> always catch it when the function changes.

That is not the point of this suggestion.  It would simply be to ensure  
changes from an lvalue to an rvalue don't compile.  It would only be used  
in those cases.

In other words, ref at callsite means "I have an lvalue".  If that  
changes, no compilation.

-Steve


More information about the Digitalmars-d mailing list