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
