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

[Walter Bright]

On 1/25/2019 7:44 PM, Manu wrote:
> I never said anything about 'rvalue references',

The DIP mentions them several times in the "forum threads" section. I see you 
want to distinguish the DIP from that; I recommend a section clearing that up.

However, my points about the serious problems with @disable syntax remain.

A section comparing with the C++ solution is necessary as well, more than the 
one sentence dismissal. For example, how C++ deals with the:

     void foo(const int x);
     void foo(const int& x);

situation needs to be understood and compared. Failing to understand it can lead 
to serious oversights. For example, C++ doesn't require an @disable syntax to 
make it work.


>> [...]
>> 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)."

I don't see how that addresses implicit type conversion at all.


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

It's not good enough. The DIP needs to specifically address what happens with 
implicit conversions. The reader should not be left wondering about what is 
implied. I often read a spec and think yeah, yeah, of course it must be that 
way. But it is spelled out in the spec, and reading it gives me confidence that 
I'm understanding the semantics, and it gives me confidence that whoever wrote 
the spec understood it.

(Of course, writing out the implications sometimes causes the writer to realize 
he didn't actually understand it at all.)

Furthermore, D has these match levels:

     1. exact
     2. const
     3. conversion
     4. no match

If there are two or more matches at the same level, the decision is made based 
on partial ordering. How does adding the new ref/value overloading fit into that?


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

It's so, so easy to get that wrong. C++ benefits from decades of compiler bug 
fixes with that.


> Nobody else that did the community reviews flagged it,

That's unfortunately right. Note that 'alias this' was approved and implemented, 
and then multiple serious conceptual problems have appeared with it. I don't 
want a repeat of that.


> and that includes you and Andrei, as members of the community.

The idea was that Andrei & I wouldn't get too involved in the DIPs until they 
are vetted by the community. I.e. delegation.


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

I look forward to a much improved DIP from you (and anyone else who wishes to 
help you out with the work!).