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

[Manu]

On Mon, Jan 28, 2019 at 9:25 AM Andrei Alexandrescu via
Digitalmars-d-announce <digitalmars-d-announce at puremagic.com> wrote:
>
> On 1/24/19 2:18 AM, Mike Parker wrote:
> > Walter and Andrei have declined to accept DIP 1016, "ref T accepts
> > r-values", on the grounds that it has two fundamental flaws that would
> > open holes in the language. They are not opposed to the feature in
> > principle and suggested that a proposal that closes those holes and
> > covers all the bases will have a higher chance of getting accepted.
> >
> > You can read a summary of the Formal Assessment at the bottom of the
> > document:
> >
> > https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md
>
> Hi everyone, I've followed the responses to this, some conveying
> frustration about the decision and some about the review process itself.
> As the person who carried a significant part of the review, allow me to
> share a few thoughts of possible interest.
>
> * Fundamentally: a DIP should stand on its own and be judged on its own
> merit, regardless of rhetoric surrounding it, unstated assumptions, or
> trends of opinion in the forums. There has been a bit of material in
> this forum discussion that should have been argued properly as a part of
> the DIP itself.
>
> * The misinterpretation of the rewrite (expression -> statement vs.
> statement -> statement) is mine, apologies. (It does not influence our
> decision and should not be construed as an essential aspect of the
> review.) The mistake was caused by the informality of the DIP, which
> shows rewrites as a few simplistic examples instead of a general rewrite
> rule. Function calls are expressions, so I naturally assumed the path
> would be to start with the function call expression. Formulating a
> general rule as a statement rewrite is possible but not easy and fraught
> with peril, as discussion in this thread has shown. I very much
> recommend going the expression route (e.g. with the help of lambdas)
> because that makes it very easy to expand to arbitrarily complex
> expressions involving function calls. Clarifying what temporaries get
> names and when in a complex expression is considerably more difficult
> (probably not impossible but why suffer).
>
> * Arguments of the form: "You say DIP 1016 is bad, but look at how bad
> DIP XYZ is!" are great when directed at the poor quality of DIP XYZ.
> They are NOT good arguments in favor of DIP 1016.
>
> * Arguments of the form "Functions that take ref parameters just for
> changing them are really niche anyway" should be properly made in the
> DIP, not in the forums and assumed without stating in the DIP. Again,
> what's being evaluated is "DIP" not "DIP + surrounding rhetoric". A good
> argument would be e.g. analyzing a number of libraries and assess that
> e.g. 91% uses of ref is for efficiency purposes, 3% is unclear, and only
> 6% is for side-effect purpose. All preexisting code using ref parameters
> written under the current rule assumes that only lvalues will be bound
> to them. A subset of these functions take by ref for changing them only.
> The DIP should explain why that's not a problem, or if it is one it is a
> small problem, etc. My point is - the DIP should _approach_ the matter
> and build an argument about it. One more example from preexisting code
> for illustration, from the standard library:
>
> // in the allocators API
> bool expand(ref void[] b, size_t delta);
> bool reallocate(ref void[] b, size_t s);
>
> These primitives modify their first argument in essential ways. The
> intent is to fill b with the new slice resulted after
> expansion/reallocation. Under the current rules, calling these
> primitives is cumbersome, but usefully so because the processing done
> requires extra care if typed data is being reallocated. Under DIP 1016,
> a call with any T[] will silently "succeed" by converting the slice to
> void[], passing the temporary to expand/reallocate, then return as if
> all is well - yet the original slice has not been changed. The DIP
> should create a salient argument regarding these situations (and not
> only this example, but the entire class). It could perhaps argue that:
>
> - Such code is bad to start with, and should not have been written.
> - Such code is so rare, we can take the hit. We then have a
> recommendation for library writers on how to amend their codebase (use
> @disable or some other mechanisms).
> - The advantages greatly outweigh this problem.
> - The bugs caused are minor easy to find.
> - ...
>
> Point being: the matter, again should be _addressed_ by the DIP.
>
> * Regarding our recommendation that the proposal is resubmited as a
> distinct DIP as opposed to a patch on the existing DIP: this was not
> embracing bureaucracy. Instead, we considered that the DIP was too poor
> to be easily modified into a strong proposal, and recommended that it be
> rewritten simply because it would be easier and would engender a
> stronger DIP.
>
> * 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. As
> anyone who has submitted a conference paper, that's not how it works,
> and even if the process is highly frustrating (yes, reviewers in so many
> cases misunderstand parts of the paper...) it does lead to strong work.
> There are cases in which papers are "accepted with amends" - those are
> strong submissions that have a few issues that are easily fixable. With
> apologies, we do not consider this DIP to be in that category.
>
> This result was frustrating and disheartening on our side, too: a
> stronger DIP should have resulted after all these years. I encourage
> interested people to make a DIP that is scientifically-argued, clearly
> formalized, and provides a thorough analysis of the consequences of the
> proposed design.
>
>
> Hope this helps,
>
> Andrei

A few things in here...

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"
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.
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".
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?
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.
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.
7. Your general tone is superior, as usual.

If it's so terrible as you say, after having survived community
treatment and approval, then I suggest there's a serious problem in
process. As you've already made clear, I'm not qualified to address
this.

> Hope this helps,

Sure.