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

[Manu]

On Fri, Jan 25, 2019 at 10:20 PM Walter Bright via
Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
>
> 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.

I think the `@disable` semantic is correct; I understand your
criticism that you have to search for the negative to understand the
restruction, but that perspective arises presumably from a presumption
that you want to explicity state inclusion, which is the opposite of
the intent.
The goal is to state exclusion, we are *adding* restrictions (ie,
removing potential calls) from the default more-inclusive behaviour,
and from that perspective, `@disable` is in the proper place.

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

C++ doesn't desire a @disable semantic, it just works as described in this DIP.

Eg:

```c++
void fun(const int& x) {}
void test()
{
    fun(10);
    fun(short(10)); // <- no problem!
}
```

It's the dlang critics of this functionality that demand explicit
controls on functions accepting one kind or the other.
I personally see no value in all that noise, but I added it in due to
popular demand.

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

It explicitly permits it as one of the goals of the DIP. Uniformity in
function calling is one of the main goals here.

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

As I said above, it couldn't be stated more clearly in the DIP; it is
very explicitly permitted, and stated that "the user should not
experience any difference in calling semantics when using ref".

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

Okay, but it is spelled out. How could I make it clearer?

> (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?

I haven't described this well. I can try and improve this.
Where can I find these existing rules detailed comprehensively? I have
never seen them mentioned in the dlang language reference.
It's hard for me to speak in these terms, when I've never seen any
text in the language spec that does so.

Note; this criticism was nowhere to be found in your rejection text,
and it would have been trivial during community reviews to make this
note.
I feel like this is a mostly simple revision to make.

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

I think my revision is water-tight (up a few posts). If the new
rewrite were written by hand and had some problem there, then there's
a serious problem with core language.

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

I couldn't have used D to solve so many problems over the years
without `alias this`. If we refuse struct inheritence, then without
`alias this`, we're screwed.

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

You're still members of the community. If something slipped through
community review that you could have easily spotted, then the strategy
you describe is no good.
If you had have spotted it 4-5 months ago, I would have wasted a LOT
less time... and now you're asking me to sign up for another few
hundred days of do-over from square-1.
I'd suggest that feedback at community-review stage would have been
extremely valuable.

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

That's good, but telling me to start over rather than revise is
unbelievably annoying and de-motivating.

I'd like you and Andrei to revise the response at the end of the
rejected DIP to remove the text that is erroneous. It's not fair to
present a rejection where a good portion of the detailed reasoning is
just plain wrong.
By my reading, there will only be one paragraph left, and then the
motivation for a hard rejection will look very different.