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:
https://wiki.dlang.org/DIP27
listed as a draft, last change Sep 2014. I don't see it in the new DIP
repository:
https://github.com/dlang/DIPs
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.
Thanks,
Andrei
