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

[Manu]

On Sat., 21 Jul. 2018, 12:30 pm Johnatune via Digitalmars-d, <
digitalmars-d at puremagic.com> wrote:

> I was for this back when it was only for 'const ref' but that
> somehow changed to just ref. Which I think is a mistake. Yes D's
> const is broken and useless, but I don't think that's a reason to
> introduce difficult to locate bugs with the addition of this
> feature. There's not a simple way to locate where code might be
> breaking if a temporary value is being passed to a ref function
> when it wasn't intended. Right now this is a compiler error, even
> in C++. But with this proposed change it might take a lengthy
> amount of time in the debugger trying to understand what is
> happening.
>
> Yes I want rvalue refs, just not like this.
>

It's like you didn't read the DIP.

I was initially very hesitant as you, but I was motivated to remove the
const restriction when I realised that usefulness of the pattern far
exceeds what you're familiar with in C++.
While interacting with interfaces similar to C++ is one motivating use case
(particularly for myself), I realised that pipeline programming and 'return
ref' change the game.
They are distinctly "D" coding styles, and this issue is a cause of
friction with respect to one of D's greatest success stories.
Such use with pipelines and 'return ref' imply that mutable ref also
supported.

There is indeed also the restrictive-const issue, and the current
recommendation is to not over-use const. From that perspecetive, this DIP
is in-line with current recommendations regarding const; it is obviously
naturally supported, but not mandated.

Finally, I have really thought about the problem case that everyone is so
terrified about, and I am still trying to visualise real-world situations
where that could arise. Please read the replies to Jonathan's sub-thread...
that has all the detail on that.

TLDR:
  - The fear in question relates to a general class of problem and not
specifically related to 'ref' - that's just one of very many ways to expose
the 'accidentally modified an rvalue' issue.
  - I don't believe it's within 'ref's responsibility domain to fight that
class of problem, particularly at the expense of the other advantages we're
inhibiting (proposed in thie DIP).
  - We're still trying to identify probably real-world examples.
  - Your fear is mostly invalid. And even if it's not, the DIP proposes a
very nice and principled mechanism to retain "lval-only please" API design.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20180721/07bdeb51/attachment.html>