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

[Manu]

On 24 March 2018 at 00:04, Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Saturday, March 24, 2018 01:37:10 Nick Sabalausky  via Digitalmars-d
> wrote:
>> On 03/23/2018 07:46 PM, Jonathan M Davis wrote:
>> > On Friday, March 23, 2018 22:44:35 Nick Sabalausky via Digitalmars-d
> wrote:
>> >> It never made any sense to me that there could be any problem
>> >> with the compiler automatically creating a temporary hidden
>> >> lvalue so a ref could be taken. If there IS any problem, I can
>> >> only imagine it would be symptomatic of a different, larger
>> >> problem.
>> >
>> > It can be a serious API problem if you can't look at ref and know that
>> > the intention is that the original argument's value will be used and
>> > then mutated (whereas with out, it will be mutated, but the original
>> > value won't be used).
>>
>> ???. That's equally true when an lvalue is passed in.
>>
>> > However, that could be solved by having a different attribute indicate
>> > that the idea is that the compiler will accept rvalues and create
>> > temporaries for them if they're passed instead of an lvalue. Then, the
>> > situation is clear.
>> Why require the callee's author to add boilerplate? Just do it for all
>> ref params that are given an rvalue.
>
> Because if the point of the function accepting its argument by ref is
> because it's going to mutate the argument, then it makes no sense for it to
> accept rvalues, whereas if the point of the function accepting its argument
> by ref is to just avoid a copy, then it makes sense to accept both. It
> should be clear from the API which is intended.

Write const; it's as clear as day!