I close DIP27. I won't be pursuing DIPs anymore

[Andrei Alexandrescu via Digitalmars-d]

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