On 24 March 2018 at 00:04, Jonathan M Davis via Digitalmars-d <[email protected]> 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!
