DIP 1016--ref T accepts r-values--Community Review Round 1

[Jim Balter]

On Saturday, 21 July 2018 at 01:17:40 UTC, Jonathan M Davis wrote:
> On Friday, July 20, 2018 18:04:26 Manu via Digitalmars-d wrote:
>> On Fri, 20 Jul 2018 at 18:02, Manu <turkeyman at gmail.com> wrote:
>> > [...]
>> >
>> > I think you're describing now a bug where a function returns 
>> > an lvalue, but it was meant to return an rvalue.
>>
>> Sorry, wrong way around! I meant to say:
>> I think you're describing now a bug where a function returns an
>> rvalue, but it was meant to return an lvalue (ie, a ref).
>
> The function returning an rvalue isn't necessarily a bug. It's 
> the fact that it was then used in conjunction with a function 
> that accepts its argument by ref in order to mutate it. If a 
> function accepts its argument by ref in order to mutate it, 
> then it's a but for it to be given an rvalue regardless of 
> whether the rvalue comes from. It's just that some cases are 
> more obviously wrong than others (e.g. passing foo + bad might 
> be obviously wrong, whereas passing foo.bar may be wrong but 
> look correct).
>
> - Jonathan M Davis

If the value returned by the function is not supposed to be 
mutable, then the fact that the function taking the ref parameter 
doesn't mutate it is not a bug. If it is supposed to be mutable, 
then there's an unrelated bug in the function that returns the 
value, which just happens to get caught by the current ref 
parameter restriction. The only other sort of bug is where you 
have a value that isn't supposed to be mutated and you have no 
intention of mutating it, and yet you pass it to a ref function 
parameter the express purpose of which is to mutate it, and then 
you don't use the result of that mutation ... but it's hard to 
even see that as a bug, just a pointless exercise, and it's hard 
to come up with a likely scenario where this would happen 
accidentally.

The situation is similar with a property that either isn't 
supposed to be mutable and you don't expect to mutate it and 
don't use its changed value yet pass it to a ref parameter the 
express purpose of which is to mutate it, or the property is 
supposed to be mutable but isn't and the current ref parameter 
restriction just happens to catch that unrelated bug.

I've read this exchange carefully and so far I agree with Manu's 
reasoning and the value of the DIP as it stands, and I'm not in 
favor of requiring @rvalue, as that negates much of the intent. 
However, I'm a D neophyte so I could well be missing something.