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

[Andrei Alexandrescu]

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