January 29, 2019
On Tuesday, 29 January 2019 at 08:35:11 UTC, Manu wrote:
> 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 _think_ what is meant is:

void[] allocate(size_t size);
bool reallocate(ref void[] b, size_t s);
void deallocate(ref void[]);

T[] arr = allocate(42);
arr.reallocate(8192); // reallocates a temporary as T[] is cast to void
arr.deallocate(); // double free


January 29, 2019
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
January 29, 2019
On 1/29/19 6:38 AM, Nicholas Wilson wrote:
> On Tuesday, 29 January 2019 at 08:35:11 UTC, Manu wrote:
>> 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 _think_ what is meant is:
> 
> void[] allocate(size_t size);
> bool reallocate(ref void[] b, size_t s);
> void deallocate(ref void[]);
> 
> T[] arr = allocate(42);
> arr.reallocate(8192); // reallocates a temporary as T[] is cast to void
> arr.deallocate(); // double free

Affirmative. (Just wrote about the same in another post). Thanks very much.

Andrei

January 29, 2019
On 1/29/19 6:45 AM, Andrei Alexandrescu wrote:
> It is truly remarkable that DIP 1016 provides not only a solution to the problem, but almost neglects to mention it.

Meant "...not only no solution..."
January 29, 2019
On Monday, 28 January 2019 at 17:23:51 UTC, Andrei Alexandrescu wrote:
> * Regarding the argument "why not make this an iterative process where concerns are raised and incrementally addressed?" We modeled the DIP process after similar processes - conference papers, journal papers, proposals in other languages. There is a proposal by one or more responsibles, perfected by a community review, and submitted for review. This encourages building a strong proposal - as strong as can be - prior to submission. Washing that down to a negotiation between the proposers and the reviewers leads to a "worst acceptable proposal" state of affairs in which proposers are incentivized to submit the least-effort proposal, reactively change it as issues are raised by reviewers.

Fair enough.
January 30, 2019
I'm on the reviewers side here.

To be honest I never liked this DIP and maybe I'll sound dumb but I think this is a case where this could bring more problem than anything.

The way I see this would be more like a syntax sugar to create temporary variable for ref parameters and that's it.

But what I fail to see is why can't the programmer solve this themselves instead of relying on a new feature that would cause more harm?

With overload some could do:

void f(int i){
    f(i);
}

void f(ref int i){
    ++i;
    writeln(i);
}

void main(){
    int i = 0;
    f(10);
    f(i);
}

prints:
11
1

The "f" function will work with ref or literal (rvalues).

But this will be controlled by the programmer the way they want it.

Donald.
January 30, 2019
On Wednesday, 30 January 2019 at 00:25:17 UTC, Don wrote:
> But what I fail to see is why can't the programmer solve this themselves instead of relying on a new feature that would cause more harm?

> Donald.

...Did you even read the arguments in the dip? This has been discuss quite a lot in the forums, it even gives you links to them.
January 30, 2019
On Wednesday, 30 January 2019 at 03:01:36 UTC, 12345swordy wrote:
> On Wednesday, 30 January 2019 at 00:25:17 UTC, Don wrote:
>> But what I fail to see is why can't the programmer solve this themselves instead of relying on a new feature that would cause more harm?
>
>> Donald.
>
> ...Did you even read the arguments in the dip? This has been discuss quite a lot in the forums, it even gives you links to them.

Well, I read the DIP and the whole forum discussion back in the day, and again I think this will create more harm than benefits the way it was proposed.

And starting from the beginning of this DIP - Rationale example:

   "void fun(int x);

    fun(10); // <-- this is how users expect to call a typical function
    But when ref is present:

    void fun(ref int x);

    fun(10); // <-- compile error; not an lvalue!!
    Necessitating the workaround:

    int temp = 10;
    fun(temp);

    This inconvenience extends broadly to every manner of rvalue passed to
    functions, including:"

So the solution in the way I understood is pretty much a syntax sugar, creating temporary variable with destruction.

But the concept is weird, because originally your function signature has a "ref parameter" and we're just creating a workaround expanding it to handle rvalues.

I would prefer to handle it myself with overloading instead of being presented with new language feature creating different scenarios for something that's not the case right now.

Otherwise D will be pretty much like C++ and in this case why bother with it?

Donald.
January 29, 2019
On 1/29/2019 3:45 AM, Andrei Alexandrescu wrote:
> 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);
> }

Even simpler:

  void func(ref void* p) {
    free(p);	                  // frees (1)
    p = malloc(100);              // (2)
  }

  int* p = cast(int*)malloc(16);  // (1)
  func(p);                        // p copied to temp for conversion to void*
  free(p);                        // frees (1) again
                                  // (2) is left dangling

It's a memory corruption issue, with no way to detect it.
January 30, 2019
On Wednesday, 30 January 2019 at 04:34:46 UTC, Don wrote:
> On Wednesday, 30 January 2019 at 03:01:36 UTC, 12345swordy wrote:
>> On Wednesday, 30 January 2019 at 00:25:17 UTC, Don wrote:
>>> But what I fail to see is why can't the programmer solve this themselves instead of relying on a new feature that would cause more harm?
>>
>>> Donald.
>>
>> ...Did you even read the arguments in the dip? This has been discuss quite a lot in the forums, it even gives you links to them.
>
> Well, I read the DIP and the whole forum discussion back in the day, and again I think this will create more harm than benefits the way it was proposed.
> Donald.

I do not accept gut feeling as a valid objection here. The current workarounds is shown to be painful as shown in the dip and in the discussions that it currently link. That *the* motivation here.
I am familiar with the author here, he is very involved with the C++<->D compatibility side of things. He knows the pain from first hand experience.

-Alex