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

Manu turkeyman at gmail.com
Thu Jan 24 09:31:41 UTC 2019


Hooray!
Who didn't see that coming 10 years off!

I understand the criticism, the most critical issue seems relatively
trivial and easy to patch (initialisation order), but this comment is
a problem for me "However, this proposal does not maintain the
distinction and instead conflates the two cases".
It's not like that's an accident, or I didn't think of this. The whole
point of this proposal is to lift an arbitrary restriction, thereby
achieving the 2 use cases stated on the opening paragraph, and
increasing language uniformity by removing edges.
"Maintaining the distinction" assumes an approach that is not lifting
one restriction and thereby creating greater uniformity in the
language, but rather, creating 2 more distinct sources of rules, and
that's not attractive as a solution space at all. We've talked about
solutions to this problem that involve adding more rules extensively,
and they're not satisfying.
So it's not because I'm an idiot that I conflated them, it's because
that's literally the point.

Then there's this one:
"The first problem the Language Maintainers identified with this
approach is that the rewrite is from an expression to a statement,
rendering it invalid"
And then present this snippet:
```
fun(10)
==>
{
  T __temp0 = void;
  fun(__temp0 := 10);
}
```
I'm upset by this comment, because it's almost like a deliberate
misrepresentation...
Not only did I never suggest anywhere that the intent is to translate
an expression into a statement, but the following examples demonstrate
why it's expanded that way with more complex compound statements, ie:
```
void fun(ref int x, ref int y);
int gun(ref int x);

fun(10, gun(20));  // <- clearly a statement
```
But even the simplest form introduced first (and presented as
evidence) DOES HAVE A SEMICOLON on the end in my DIP, but removed from
the review?
So I can't agree with this comment: "The expression should be
rewritten as an expression to clarify how it behaves in larger
expressions."; this whole thing is about statements, not expressions.
Misunderstanding that is to misunderstand the proposal entirely.

So my feeling is that this initial point "First, reasoning about the
proposed semantics is futile, as they are built upon a flawed
foundation" is just plain invalid, the suggestion I'm talking about
expressions is incorrect.
And that invalidates this second point "Second,reasoning about the
consequences of potentially revised semantics is equivalent to
considering a new DIP."
I think it's possible to consider this DIP, but the suggestion is that
something other than what I wrote is what has been considered.

Anyway, I can only blame myself for somehow failing to communicate
these details, although I don't know how I managed that.

The criticism about initialisation ordering is absolutely fair, and I
suspect it requires a small amount of tweaking (perhaps initialising
eagerly, or rather just expanding the code and ordering/sequencing the
expansion a little more carefully), to address the
throwing-an-exception mid-statement issue, and not an entirely
different DIP written by someone competent like Timon.

I think all of that is mostly just fluff to lend weight to this
critical sentence "The Language Maintainers insist that any proposal
allowing ref parameters to accept rvalue references must clearly
define how functions which make use of ref for side effects will not
accept rvalues."
And that's 'just like, your opinion man'. A key point is for functions
that do side-effects to receive rvalues too, and this was arrived at
after much community discussion. We identified real cases where we
*want* functions that receive rvalues to do side-effects,
specifically, UFCS chains are frequently broken by need to capture an
lvalue mid-steam.
Pipeline programming is a big deal, and improving that experience was
a motivator for this proposal.

This process is pretty unsatisfying, because it ships off to a
black-box committee, who were apparently able to misunderstand the
substance of the proposal and then not seek clarification, and despite
the only legitimate issue from my perspective being easily corrected,
it's been suggested to start a whole new DIP.

On Wed, Jan 23, 2019 at 11:20 PM Mike Parker via
Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
>
> Walter and Andrei have declined to accept DIP 1016, "ref T
> accepts r-values", on the grounds that it has two fundamental
> flaws that would open holes in the language. They are not opposed
> to the feature in principle and suggested that a proposal that
> closes those holes and covers all the bases will have a higher
> chance of getting accepted.
>
> You can read a summary of the Formal Assessment at the bottom of
> the document:
>
> https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md


More information about the Digitalmars-d-announce mailing list