DIP 1016--ref T accepts r-values--Formal Assessment
SeeWebsiteForEmail at erdani.com
Mon Jan 28 17:23:51 UTC 2019
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
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
* 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
Hope this helps,
More information about the Digitalmars-d-announce