www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Up-to-date DIPs list

reply Seb <seb wilzba.ch> writes:
Hey all,

tl;dr: D's DIPs seem not maintained. A couple of ideas are 
proposed to tackle this state.

I really like the List of D Improvement Proposals 
(http://wiki.dlang.org/DIPs), however it seems to me that they 
are lacking a maintainer.
Let me briefly state what I found:

1) Many DIPs have already been implemented and merged or at least 
they are in progress.

http://wiki.dlang.org/DIP22 Private symbol (in)visibility
http://wiki.dlang.org/DIP29 Unique pointers
http://wiki.dlang.org/DIP43 Objective-C (in progress, partially 
merged?)

2) Moreover I found a couple of DIPs that turned out to be 
unfeasible or too much work for the author.

http://wiki.dlang.org/DIP63 Operator overloading for raw templates

3) There are also DIPs that have been superseeded by other:

http://wiki.dlang.org/DIP36 Rvalue References (by #69)

This list is not complete by any means. The general summary is 
that for draft DIPs only the author really knows its current 
status and well most DIPs are drafts...

As I really like those DIPs and it's sad to see them in such a 
careless shape, I have a couple of ideas that might help to avoid 
this in the future:

Idea 1 Have a bit more "formal" DIP protocol
--------------------------------------------

Currently everyone can add his/her new proposal and imho that's 
very nice - however it leads to the problem of stalled DIPs. 
Introducing a "Stalled" state and having an (automated) process 
that looks over it could help too see which DIPs are in work and 
closed (stalled is very similar to closed).

I) Have a maximal draft period of six month
II) After draft there can be four states: "In progress", 
"Rejected",  "Stalled", "Superseded".
III) Define these follow-up states:

Approved = positive approval of the implementation by the 
community and merged into master [end state]
Rejected = negative approval by the community (e.g. major flaws 
or too complicated) [end state]
Stalled = No activity within six months (most likely an end state)
Superseded = Replaced by a newer DIP [end state]

Draft ---> In progress -->  Implemented  --> Approved
   |        ^    |  |            |
   |        |    |  |            |
   |-> Stalled <-|  |            |
   |       |        |            |
   v       v        v            |
(Rejected || Superseded) <------|


Idea 2 Use a version control system (aka git)
---------------------------------------------

Some troubles - like formal review & automated up-to-date status 
- could be easily solved by putting the DIPs into a git 
plain-text "database".


Idea 3 Getting back to the roots: PEPs
--------------------------------------

https://www.python.org/dev/peps/
https://www.python.org/dev/peps/pep-0001/

Their workflow is sophisticated, why not getting inspired again?
Short summary - read PEP #0001 for more details:

I) The PEP champion (a.k.a. Author) should first attempt to 
ascertain whether the idea is PEP-able. Posting to the 
[newsgroup/mailing list]
II) Idea proposal -- submitted to --> PEP editors (which have the 
right to reject PEP proposals if they appear too unfocused or too 
broad)
III) PEP editors -- assign --> a number to PEP
IV) Draft PEP may be discussed further
V) Once a PEP is completed a PEP, the author may request a review 
for style and consistency from the PEP editors. However, the 
content and final acceptance of the PEP must be requested of the 
BDFL [Benevolent Dictator For Life, Guido van Rossum], usually 
via an email. PEPs are reviewed by the BDFL and his chosen 
consultants, who may accept or reject a PEP or send it back to 
the author(s) for revision. For a PEP to be accepted it must meet 
certain minimum criteria:
  - It must be a clear and complete description of the proposed 
enhancement.
  - The enhancement must represent a net improvement.
  - The proposed implementation, if applicable, must be solid and 
must not complicate the interpreter unduly.
VI) When a PEP is Accepted, Rejected or Withdrawn, the PEP should 
be updated accordingly.

-----------------------------

Those are just some ideas I wanted to send out to you - feel free 
to combine, destroy, cherry-pick them or to add your own ideas ;-)

Cheers,

Seb
Mar 12 2016
parent reply ZombineDev <petar.p.kirov gmail.com> writes:
On Saturday, 12 March 2016 at 12:49:42 UTC, Seb wrote:
 Hey all,

 tl;dr: D's DIPs seem not maintained. A couple of ideas are 
 proposed to tackle this state.

 [...]
+1 The formal process required for library additions to std.experimental was a step in the right direction, IMO. Rust also has well written document on this topic: https://github.com/rust-lang/rfcs/blob/master/README.md I think you should structure your proposal as a DIP. For example: http://wiki.dlang.org/DIP75 http://wiki.dlang.org/Review/Process You also probably link it from the overview page (http://wiki.dlang.org/DIPs). BTW all documents describing formal processes (review, release), design rational, etc. should be better organized.
Mar 16 2016
parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Wednesday, 16 March 2016 at 14:28:10 UTC, ZombineDev wrote:
 On Saturday, 12 March 2016 at 12:49:42 UTC, Seb wrote:
 Hey all,

 tl;dr: D's DIPs seem not maintained. A couple of ideas are 
 proposed to tackle this state.

 [...]
+1
[...]
 You also probably link it from the overview page 
 (http://wiki.dlang.org/DIPs).

 BTW all documents describing formal processes (review, 
 release), design rational, etc. should be better organized.
+1 I think there should be the possibility to up-vote a post in the forum, so that it gets more clear what topics are of high interest and which not. Even if no additional comment is made. So very useful threads can be found and used as information starting point even if they get out of focus by time. Posts with high ranking, can be detected and used to optimize the general language documentation. And DIP discussions. Same for DUB packages, my suggestion was to show the GitHub Stars and the number of watchers and or number of downloads, Sönke said he will look at it, if he finds the time... Just my 2 cent. mt.
Mar 16 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 16 March 2016 at 16:26:02 UTC, Martin Tschierschke 
wrote:

 I think there should be the possibility to up-vote a post in 
 the forum,
 so that it gets more clear what topics are of high interest and
 which not. Even if no additional comment is made.

 So very useful threads can be found and used as information 
 starting point even if
 they get out of focus by time. Posts with high ranking, can be 
 detected and used to optimize the general language 
 documentation. And DIP discussions.
This is not an independent forum. It's a web interface to a newsgroup server, which also has a mailing list interface that many people use. Yes, it would be possible to implement something like that for the web interface alone, but I don't see how that would add any value.
Mar 16 2016
parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Thursday, 17 March 2016 at 03:58:49 UTC, Mike Parker wrote:
 On Wednesday, 16 March 2016 at 16:26:02 UTC, Martin 
 Tschierschke wrote:

 I think there should be the possibility to up-vote a post in 
 the forum,
 so that it gets more clear what topics are of high interest and
 which not. Even if no additional comment is made.

 So very useful threads can be found and used as information 
 starting point even if
 they get out of focus by time. Posts with high ranking, can be 
 detected and used to optimize the general language 
 documentation. And DIP discussions.
This is not an independent forum. It's a web interface to a newsgroup server, which also has a mailing list interface that many people use. Yes, it would be possible to implement something like that for the web interface alone, but I don't see how that would add any value.
The forum is sorted by time, latest first. But what if you are new to the language? Like me. Which threads are worth reading even if they are older? Or if a discussion is going on since many month/years do I have to read all? What are the best arguments? Isn't the forum full of hints and best practice tips which should be available easier? Keeping it in the way it is in the moment, makes it difficult to find the treasures inside. But you need both, the possibility to vote and an overview of threads and post with highest votes. Best regards mt.
Mar 17 2016
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 17 March 2016 at 10:11:14 UTC, Martin Tschierschke 
wrote:

 Isn't the forum full of hints and best practice tips which 
 should be available easier?
 Keeping it in the way it is in the moment, makes it difficult 
 to find the treasures
 inside.
There's a search box at the top of the page.
 But you need both, the possibility to vote and an overview of 
 threads and post with
 highest votes.
I understand your reasoning, I'm just of the opinion that if it can't be implemented across all of the interfaces (and it really can't), then it doesn't make sense to do it. If we had a wholly contained forum, it would be a different story.
Mar 17 2016
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Thursday, 17 March 2016 at 10:11:14 UTC, Martin Tschierschke 
wrote:
 But you need both, the possibility to vote and an overview of 
 threads and post with
 highest votes.
Don't be offended, but I think we are a bit off-topic here - my suggestions were about better ways to manage DIPs. What do you think about putting them into a Github repo for a first start so that potential tooling or standardization gets a lot easier?
Mar 17 2016
parent Martin Tschierschke <mt smartdolphin.de> writes:
On Thursday, 17 March 2016 at 19:03:31 UTC, Seb wrote:
 On Thursday, 17 March 2016 at 10:11:14 UTC, Martin Tschierschke 
 wrote:
 But you need both, the possibility to vote and an overview of 
 threads and post with
 highest votes.
Don't be offended, but I think we are a bit off-topic here - my suggestions were about better ways to manage DIPs. What do you think about putting them into a Github repo for a first start so that potential tooling or standardization gets a lot easier?
You are right, its getting off-topic, ;-) unfortunately I am not very familiar with all Git tooling, but I appreciate the idea that better tooling is needed and so Git should be a good solution, because it is used anyway by the "D-crowd". Regards mt.
Mar 21 2016