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

[Andrei Alexandrescu]

On 1/29/19 3:35 AM, Manu wrote:
> 1. All of this is more useful criticism than the official and final
> criticism affixed to the rejection, which when revised to remove the
> incorrect criticisms, is basically left with the text "The Language
> Maintainers found other issues with the proposal, most of which may
> have been remedied through simple revision"

No. This is a nonnegotiable matter:

void bump(ref int x) { ++x; }
short y = 42;
bump(y);
assert(y == 43); // fails

The code above should not compile. The DIP allows it to compile. We 
didn't see how the DIP can be lightly edited to fix this problem, so we 
recommended a complete rethinking and rewrite.

> 2. All of this criticism could have been given at any point in the
> past half a year or so prior to submission, and that would have been
> appreciated, rather than wasting our time.

We have given this criticism ever since ten years ago when you brought 
the matter up. Literally every time, including in person. Whenever you 
said "why not bind rvalues to ref?" we religiously replied with 
(paraphrased of course) "We are worried about rvalues resulting from 
implicit conversion of lvalues. You'd need to find a solution to that."

It is truly remarkable that DIP 1016 provides not only a solution to the 
problem, but almost neglects to mention it.

> 3. "It does not influence our decision and should not be construed as
> an essential aspect of the review"  <--  Then why did it feature as
> one of just 3 core criticism in the rejection text? And supplied as
> one of the 2 reasons that could not "have been remedied through simple
> revision".

If the matter above can be resolve through simple revision that would be 
great. I don't think it can, but would love to be proven wrong!

> 4. "Under DIP 1016, a call with any T[] will silently "succeed" by
> converting the slice to void[]"  <--  Do you mean "... with any T[]
> rvalue ..."? What would be the aim of that call? Can you suggest a
> particularly sinister construction?

I am talking about this:

int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
if (alloc.reallocate(a, 200 * int.sizeof)
{
     assert(a.length == 200);
}

By applying the lowering rules in the DIP (including your pending 
revision), the code is lowered to:

int[] a = cast(int[]) alloc.allocate(100 * int.sizeof);
void[] __temp0 = a;
if (alloc.reallocate(__temp0, 200 * int.sizeof)
{
     assert(a.length == 200);
}

The code is far from sinister. But the assertion will fail.

I want to make sure there is mutual understanding that:

1. DIP 1016 proposes this semantics
2. We do not accept this semantics

Even if there is no agreement with (2), these are facts that I want to 
make sure are understood by everyone involved - you, us, the rest of the 
community.

> 5. "and recommended that it be rewritten simply because it would be
> easier and would engender a stronger DIP."  <--  I wrote the DIP I
> wrote... your official feedback affixed to the bottom of the DIP was
> pretty much entirely unhelpful, almost offensively so. I would just
> write the same DIP if I started again. I genuinely hope someone can be
> bothered to do this. After 10 years on this, I think I'm over it.

I am sorry you found the review unfit for your needs. I thought it puts 
the main matter plain and simple: we do not accept code like this:

void bump(ref int x) { ++x; }
short y = 42;
bump(y);
assert(y == 43); // fails

Honest, I don't think you have spent 10 years on this DIP. It is not 
thorough work and fails to address the main problem it was supposed to 
address: The one above.

> 6. "This result was frustrating and disheartening on our side, too: a
> stronger DIP ..."  <--  I'm sorry you hated it. You could have
> reviewed it at any point, made suggestions at any point, written it
> yourself, or encouraged someone competent to do it.

We didn't hate it. We made suggestions literally every time you brought 
up the issue over the past decade. For my part, I have no idea what more 
input I could have provided. "Solve the rvalues coming from implicit 
conversions" is all feedback the DIP needs.

> 7. Your general tone is superior, as usual.

No need to attempt to make this personal, and claim the moral ground in 
the process. Nobody is after you. We all want the D language to become 
better. The DIP is not good. This is what it is.

All is not lost - the DIP is a good inspiration for a couple of ideas 
that deserve investigation. It seems that allowing _only_ rvalues to be 
bound to ref may work. I'm cautious because there may be cases we didn't 
think of.


Andrei