DIP 1016--ref T accepts r-values--Formal Assessment
newshound2 at digitalmars.com
Sat Jan 26 06:15:22 UTC 2019
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:
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
I look forward to a much improved DIP from you (and anyone else who wishes to
help you out with the work!).
More information about the Digitalmars-d-announce