On 10/17/2016 01:02 AM, Walter Bright wrote:
On 10/16/2016 3:17 PM, deadalnix wrote:
Long story short, it si clearly a waste of time. Qualifying the
process would be
an understatement.

Some specifically DIP27 has been written in Feb 2913, following various
discussion at that time. I pushed it at the time. I moved it to the
new git DIP
repository. Got mostly irrelevant feedback (Hi Martin) and more
generaly the
loop time is measured in month.

The wiki DIP27 is here:


listed as a draft, last change Sep 2014. I don't see it in the new DIP


either submitted, approved, or in a PR.

I understand your frustration and please bear with us while we're arranging the DIP process to guarantee timely response.

Made a pass through https://wiki.dlang.org/DIP27. It needs serious work in order for it to be considered at the level of quality we want to foster. Here are a few suggestions that may improve its chances:

* The Rationale section should present evidence and examples, instead of argumentative prose, to explain how the complexity of the language creates problems for function definitions.

* Good evidence would include e.g. bugs or contorted code in existing D projects, repeated confusion in the learn forum, undue complications in the language definition, arcane compiler implementation - anything and everything that shows this is a significant problem.

* There should be more concrete motivation and explanation on how exactly the language is simplified, and what the beneficial consequences of such simplification are (e.g. no more puzzling behavior, smaller/more precise specification, fewer corner cases etc).

* The "Function definition and uses" section and the two following ones should explain where the proposed changes diverge from the current language. The constructive definition by means of an enum is useful, but does not offer sufficient insight to estimate the issues with the existing language definition and how the proposal addresses them.

* At best, some proposed text for the language definition would be good to have, e.g. "the following paragraph in the definition: [...] shall be replaced with: [...]".

* A careful editorial pass must be done to remove the numerous typos that make the document imprecise and difficult to read.

Overall, as things stand, it is difficult for the reader to figure (a) what the benefits of the DIP are; (b) what the cost is in terms of code breakage (e.g. which constructs will break and how). Conveying a good understanding of the relationship between costs and benefits would greatly improve the DIP.

Also, one thing to keep in mind: the way we intend DIPs going forward is ideally there would be scrutiny followed by some pick up in the community before a DIP gets submitted for formal review. The DIP has been posted in the forum on 2013-02-26 and has garnered 51 follow-ups through the next day. There were 6 more changes to the document also during those two days (https://wiki.dlang.org/?title=DIP27&action=history), most minor; most importantly the "is" expression section was added (https://wiki.dlang.org/?title=DIP27&diff=2216&oldid=2210). After that the document has been unchanged (save for one semicolon added by Rainer) for over three and a half years, during which there was no subsequent community discussion either. In an ideal world there would be some more interest and action leading up to a formal review.



Reply via email to