On Thu, Jan 24, 2019 at 11:35 PM Walter Bright via Digitalmars-d-announce <[email protected]> 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...
