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

[Manu]

On Fri, 20 Jul 2018 at 12:51, Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On Friday, July 20, 2018 12:21:42 Manu via Digitalmars-d wrote:
> > I think disabling it is going to be the overwhelmingly niche case, but
> > it's good that you can still do it and be satisfied if that's what you
> > want to do.
> >
> > Can you link me to a single line of your own code where you've used
> > this pattern?
>
> What, having ref mutate its argument and that being its entire purpose for
> being there? How about almost every time I have ever used ref ever. e.g.
> this is exactly what some functions in dxml do, and it would be just plain
> wrong to pass an rvalue - e.g. the overload of parseDOM that operates on an
> EntityRange:
>
> http://jmdavisprog.com/docs/dxml/0.3.2/dxml_dom.html#.parseDOM
>
> or a function like writeTaggedText
>
> http://jmdavisprog.com/docs/dxml/0.3.2/dxml_writer.html#.writeTaggedText
>
> which writes to the XMLWriter that it's given. Having either of those accept
> rvalues would just cause bugs.
>
> In the few cases where it seems appropriate to accept both rvalues and
> lvalues without copying either, I can almost always use auto ref, because I
> rarely use classes. I agree that being able to accept lvalues without
> copying them would be useful for non-templated functions as well, but I do
> not at all agree that that is how ref should work in general. IMHO, as with
> auto ref, it really should be marked with an attribute to indicate that it
> is purposefully accepting rvalues. I would not consider it a niche case at
> all for ref to not accept rvalues.

Okay, this is such the kind of niche use case I'm describing, that the
documentation goes out of it's way to explain to the user the reason
why 'ref' may be used:

"Note that default initialization, copying, and assignment are
disabled for XMLWriter. This is because XMLWriter is essentially a
reference type, but in many cases, it doesn't need to be passed
around, and forcing it to be allocated on the heap in order to be a
reference type seemed like an unnecessary heap allocation. So, it's a
struct with default initialization, copying, and assignment disabled
so that like a reference type, it will not be copied or overwritten.
Code that needs to pass it around can pass it by ref or use the
constructor to explicitly allocate it on the heap and then pass around
the resulting pointer."

This demonstrates to me that the explicit application of @disable in
this case (and cases like it) is absolutely acceptable. It's more than
acceptable; it's entirely preferable to make the API just as explicit
as the documentation.

Secondly, given this API, I can't imagine a valid construction where
the user accidentally provided an rvalue, and the program still built
and runs (with bugs).
What conceivable bug is the rule preventing here? If the user
accidentally provided an rvalue and the function did nothing... what
would the program even do? What's the 'bug'? How would the programmer
call 'save' to write the xml to disk or whatever when the variable was
never declared anywhere. The bug prevents itself in other ways.

This link is self-defeating. Can you find more?

> > > Either way, what this DIP proposes means that existing uses of ref will
> > > need to be changed - and in an extremely verbose way - in order to get
> > > back their current behavior.
> >
> > Their currently behaviour is mostly wrong, and the exact thing I'm
> > trying to fix though.
>
> Why would the current behviour be mostly wrong? If the purpose of using ref
> is to accept the current value of a variable and mutate it such that the
> argument is mutated,

That's not "the purpose of using ref".
That is _one use_ of ref, and in my world, it's comparatively rare.

> then the current behaviour is _exactly_ what's
> desirable, and it prevents bugs.

The currently behaviour is absolutely not desired by every other
practical use of 'ref'.

I'd still like to know an example of the kinds of bugs it's preventing
that wouldn't be prevented implicitly in other ways?