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 <turkey...@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.
