DIP 1016--ref T accepts r-values--Formal Assessment

[Manu]

On Fri, Jan 25, 2019 at 4:00 AM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
>
> On 1/24/2019 11:53 PM, Nicholas Wilson wrote:
> > That the conflation of pass by reference to avoid copying and mutation is not
> > only deliberate but also mitigated by @disable.
>
> The first oddity about @disable is it is attached to the foo(int), not the
> foo(ref int). If I wanted to know if foo(ref int) takes rvalue references,

And right here, I can see our fundamental difference of perspective...

I never said anything about 'rvalue references', and I never meant
anything like that; at least, not in the C++ sense, which you seem to
be alluding to.
In C++, rval references are syntactically distinct and identifiable as
such, for the purposes of implementing move semantics.

If we want to talk about "rvalue references", then we need to be
having a *completely* different conversation.
That said, I'm not sure why you've raised this matter, since it's not
written anywhere in the DIP.

What I'm talking about is "not-rvalue-references accepting rvalues",
which if you want to transpose into C++ terms, is like `const T&`.

> There are indeed
> unlikable things about the C++ rules, but the DIP needs to pay more attention to
> how C++ does this, and justify why D differs. Particularly because D will likely
> have to have some mechanism of ABI compatibility with C++ functions that take
> rvalue references.

I'm not paying attention to C++ T&& rules, because this DIP has
nothing to do with T&&, and there would be no allusion to connecting
this to a T&& method. Again, I find that to be a very interesting
topic of conversation, but it has nothing to do with this DIP.

> [...]
> Should `s` be promoted to an int temporary, then pass the temporary by
> reference? I can find no guidance in the DIP. What if `s` is a uint (i.e. the
> implicit conversion is a type paint and involves no temporary)?

As per the DIP; yes, that is the point.
The text you seek is written: "[...]. The user should not experience
edge cases, or differences in functionality when calling fun(int x) vs
fun(ref int x)."
That text appears at least 2 times through the document as the stated goal.

Don't accept naked ref unless you want these semantics. There is a
suite of tools offered to use where this behaviour is undesirable.
Naked `ref` doesn't do anything particularly interesting in the
language today that's not *identical* semantically to using a pointer
and adding a single '&' character at the callsite. This DIP attempts
to make `ref` interesting and useful as a feature in its own right.
In discussions designing this thing, I've come to appreciate the UFCS
advantages as the most compelling opportunity, among all the other
things that burn me almost practically every time I write D code.

> The DIP should not invent its own syntax

I removed it, and replaced it with simpler code (that I think is
exception-correct) in my prior post here. It's also a super-trivial
amendment.

> It should never have gotten this far without giving a precise explanation of how
exception safety is achieved when faced with multiple parameters.

I apologise. I've never used exceptions in any code I've ever written,
so it's pretty easy for me to overlook that detail.
Nobody else that did the community reviews flagged it, and that
includes you and Andrei, as members of the community.

> All that criticism aside, I'd like to see rvalue references in D. But the DIP
> needs significant work.

This is *NOT* an "rvalue-references" DIP; this is a "references" DIP.
If you want to see an rvalue references DIP, I agree that's a
completely different development, and it's also interesting to me... I
had *absolutely no idea* that an rvalue-references DIP was welcome. I
thought D was somewhat aggressively proud of the fact that we don't
have rvalue-references... apparently I took the wrong impression.

That said, this remains infinitely more important to me than an
rvalue-references DIP. It's been killing me for 10 years, and I'm
personally yet to feel hindered by our lack of rvalue-reference
support.