January 24
On Thu, Jan 24, 2019 at 6:35 PM Walter Bright via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On 1/24/2019 4:31 PM, 12345swordy wrote:
> > And wait for another 180+ days for a fix? Come on dude, can you understand the frustration being display here?
>
> Of course it's frustrating. On the other hand, we've had a lot of problems stemming from implementing features without thoroughly understanding them.
>
> Rvalue references have a lot of subtleties to them, and we should not rush into it, especially since these issues only turned up at the last minute.

Which issues? The initialization order issue? That's relatively
trivial, isolated, and doesn't change the substance of the proposal in
any way (unless a working rewrite is impossible, which I'm confident
is not the case).
The rest of your criticisms certainly did not 'turn up at last
minute', they were extensively discussed, and discussion material is
available, and present in the community review summary.

And then there's the weird expression vs statement comments, which are bizarre, because you literally had to modify my code snippets (removing the semicolons) to read it that way... I can't accept that feedback, that just demonstrates a mis-reading of the DIP. If the DIP could be misunderstood that way, then that's surely revision-worthy, not throw-it-out-and-start-over worthy, and it has nothing to say about the substance of the design.
January 24
On Thu, Jan 24, 2019 at 6:35 PM Walter Bright via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> On 1/24/2019 4:31 PM, 12345swordy wrote:
> > And wait for another 180+ days for a fix? Come on dude, can you understand the frustration being display here?
>
> Of course it's frustrating. On the other hand, we've had a lot of problems stemming from implementing features without thoroughly understanding them.
>
> Rvalue references have a lot of subtleties to them, and we should not rush into it, especially since these issues only turned up at the last minute.

"Rush"? We've literally been debating this since my first post on this
forum... like, 10 years ago.
It's the issue I specifically joined this forum to complain about.
January 25
On Friday, 25 January 2019 at 00:31:50 UTC, 12345swordy wrote:
> On Thursday, 24 January 2019 at 23:43:21 UTC, Walter Bright wrote:
>> It's no problem if you want to rework the existing text, just submit it as a new DIP.
>
> And wait for another 180+ days for a fix? Come on dude, can you understand the frustration being display here?

This will be discussed at DConf at the DLF meeting, which is only 75ish days, along with all other DIPs that are not yet implemented, under review (incl. draft) or recently rejected and a whole host of other topics, so that we can finally get some process direction and vision happening.
January 24
On 1/24/2019 4:21 PM, Elie Morisse wrote:
> I didn't see that coming and I'm deeply frustrated and disappointed by this review and rejection.

On the contrary. It is good to find conceptual errors before implementing it. They're a LOT cheaper to fix earlier rather than when it is in the field.
January 24
On 1/24/2019 12:01 PM, kinke wrote:
> `out` params are default-initialized on entry. Ignoring backwards compatibility for a second, I think getting rid of that would actually be beneficial (most args are probably already default-initialized by the callee in the line above the call...)

The compiler should elide the default-initializations before the call (although it currently does not).

The 'out' comes from IDL (Interface Definition Language) and by using out parameters it is directly convertible to/from IDL.

Even earlier, 'out' comes from Ada (!)

From an efficiency standpoint, having the initialization occur in the function is better than all that duplicated initialization code in all the callers.
January 24
No, it is not rejected in principle. Finding serious errors in it on the eve of approval is disappointing, and is not auspicious for being in a hurry to approve it.

For example, I spent a lot of time working on ARC, and was all set to move forward with it when Timon stepped in and showed it was fundamentally memory unsafe. I couldn't come up with a reasonable solution. I'm grateful that Timon saved me from much further wasted work and embarrassment.

Rvalue references are not a simple problem (although they appear to be). I do believe the problems with it are solvable, but it is a bit unfair to the implementor to dump an incomplete spec on him and have him fill in the gaps. The statement thing is a "do what I meant, not what I wrote" example, and DIPs need to be better than that. You're leaving him to design where the temporaries go, where the gates go, and ensure everything is properly exception safe.

I know it's frustrating for you, but it's worse if an rvalue-ref implementation is implemented, shipped, and heralded, and then turns out to be very broken.
January 25
On Friday, 25 January 2019 at 07:02:47 UTC, Walter Bright wrote:
> On 1/24/2019 4:21 PM, Elie Morisse wrote:
>> I didn't see that coming and I'm deeply frustrated and disappointed by this review and rejection.
>
> On the contrary. It is good to find conceptual errors before implementing it.

You mean the conceptual errors you made when reviewing it? Like:

That the conflation of pass by reference to avoid copying and mutation is not only deliberate but also mitigated by @disable.

That the DIP applies to statements, not expressions.

That the construction order issue is trivially fixable, by specifying the same behaviour as the non ref case modulo ref.

January 25
On Friday, 25 January 2019 at 07:33:02 UTC, Walter Bright wrote:
> No, it is not rejected in principle.

Good.

> Finding serious errors in it on the eve of approval is disappointing,
> and is not  auspicious for being in a hurry to approve it.

Praytell, what serious errors? Also you should heed your own advice DIP1017 and send it back to draft.

> Rvalue references are not a simple problem (although they appear to be).

Please, do enlighten us..

> The statement thing is a "do what I meant, not what I wrote" example,

_You_ removed the semicolons. The DIP applying to statements was at worst implied by their use, and frankly quite obvious, how else could they transcend multiple expressions?


> You're leaving him to design where the temporaries go, where the gates go, and ensure everything is properly exception safe.

You could have at least had the decency to notify Manu. As noted elsewhere this problem is nowhere even close to DIP breaking, and I'm certain he could have resolved that.

January 25
On Thu, Jan 24, 2019 at 11:35 PM Walter Bright via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>
> No, it is not rejected in principle. Finding serious errors in it on the eve of approval is disappointing, and is not auspicious for being in a hurry to approve it.

I'm very clearly NOT in a hurry here. We've been sitting on this for 10 years.
What's weird is that you closed the door on iteration, and instead
suggested I should write a new one with someone competent.

More strangely, part of your feedback is broken, it appears you've
reviewed and made assessment against code and text that's just not
there, and you've neglected to respond to those points several times
now.
The error you found seems entirely revision-worthy rather than
rejection-worthy. Your comments about treating expressions as
statements is just wrong, and from that point on where you've
mis-interpreted something so fundamental to the DIP, I don't think
it's possible to trust any outcome from your 'formal assessment'.

I appreciate that you identified the exception issue, we'll fix it, but I think you need to reconsider the formal rejection.

> but it is a bit unfair to the
> implementor to dump an incomplete spec on him and have him fill in the gaps

How is that the intent? We can get the rewrite semantics right with an
iteration.
So is it rejected on that premise? I don't understand how re-reading
it with satisfactory rewrite logic going to change your assessment of
the DIP in general? No surrounding text would change, and assuming
that the rewrite is corrected, then do you just find a different
reason to reject it?
If so, then that needs to be the reason for the rejection, and not the
error in the rewrite.

I presume the real reason for rejection is this part:
"They say that with the current semantics, this function only operates
on long values as it should. With the proposed semantics, the call
will accept all shared integral types. Any similar proposal must
address this hole in order to be accepted."

But to make that criticism is to miss the point entirely. The point is
to do the thing you say needs to be addressed... and a whole bunch of
techniques to motivate the compiler to emit desirable compile errors
can be deployed in various circumstances. None of them are
particularly unpleasant or awkward.
TL;DR: use `out`, use `*`, use @disable, use const. These can and
should all be deployed appropriately anyway.

Is that the reason it was rejected? If so, then I can't fix that by
rewriting the DIP, that *is* the DIP.
If you're not persuaded by the advantages, and that (rather extensive)
set of tools to mitigate the side effects you're concerned about, then
that's really more of an opinion than a technical rejection.
I guess you're entitled to say "I don't like it, and I reject it
because I don't like it", but you have to *say* that, and not make up
some other stuff.

> The statement thing is a "do what I meant, not what I wrote" example, and DIPs need to be better than that. You're leaving him to design where the temporaries go, where the gates go, and ensure everything is properly exception safe.

I agree, we'll fix the temporaries; but getting that correct is a
revision surely. There's no spec to change there.
The criticism talking about rewriting expressions as statements is
still mysterious to me. I don't understand how a rejection can be
presented based on an incorrect reading of the DIP... and how am I
supposed to accept the rejection text containing those criticisms when
the criticisms don't address what's written?
You had to change the code (removing the semicolon from the statement)
to make the claim that I was rewriting expressions as statements, and
I honestly have no idea why you did that?

Anyway...
January 25
On Friday, 25 January 2019 at 07:33:02 UTC, Walter Bright wrote:
> No, it is not rejected in principle. Finding serious errors in it on the eve of approval is disappointing, and is not auspicious for being in a hurry to approve it.
>
> For example, I spent a lot of time working on ARC, and was all set to move forward with it when Timon stepped in and showed it was fundamentally memory unsafe. I couldn't come up with a reasonable solution. I'm grateful that Timon saved me from much further wasted work and embarrassment.
>
> Rvalue references are not a simple problem (although they appear to be). I do believe the problems with it are solvable, but it is a bit unfair to the implementor to dump an incomplete spec on him and have him fill in the gaps. The statement thing is a "do what I meant, not what I wrote" example, and DIPs need to be better than that. You're leaving him to design where the temporaries go, where the gates go, and ensure everything is properly exception safe.
>
> I know it's frustrating for you, but it's worse if an rvalue-ref implementation is implemented, shipped, and heralded, and then turns out to be very broken.

Bit ironic considering how some DIPs are being handled. Changes for dip 1000 are already being integrated in Phobos yet the dip is still only a draft and looks like part of it still needs to be rewritten. If you needed to iron out details by implementing it, then that should have been done on your own fork like everyone else instead of adding experimental code into master.
1 2 3 4 5 6 7 8 9 10 11 12 13 14