Hi,

Abstract:

D Drafting Library is an official library modeled by the D community and designed to support the development process of the D Standard Library. The drafting library is coupled with the standard library and doesn't introduce any duplicated functionality. It should be used during the drafting stage of the new functionality development.

Link to the DIP:
http://wiki.dlang.org/DIP73

and to the recent discussion for initial proposal:
http://forum.dlang.org/post/rwavdkzmkqxpldveueje@forum.dlang.org

Please comment, share your view and doubts. Don't hesitate to ask any question.

I tried to define the proposal to be almost non-intrusive for not interested developers.

I can handle point 3 and 4 from "Proposal implementation steps" section as a pull requests when proposal is accepted. Step 1 and 2 are trivial but can't be done by me as I'm not the person in charge.

Piotrek

On Wednesday, 4 February 2015 at 22:10:51 UTC, Piotrek wrote:
> Hi,
>
> Abstract:
>
> D Drafting Library is an official library modeled by the D community and designed to support the development process of the D Standard Library. The drafting library is coupled with the standard library and doesn't introduce any duplicated functionality. It should be used during the drafting stage of the new functionality development.
>
> Link to the DIP:
> http://wiki.dlang.org/DIP73
>
> and to the recent discussion for initial proposal:
> http://forum.dlang.org/post/rwavdkzmkqxpldveueje@forum.dlang.org
>
> Please comment, share your view and doubts. Don't hesitate to ask any question.
>
> I tried to define the proposal to be almost non-intrusive for not interested developers.
>
> I can handle point 3 and 4 from "Proposal implementation steps" section as a pull requests when proposal is accepted. Step 1 and 2 are trivial but can't be done by me as I'm not the person in charge.
>
> Piotrek

This looks very similar to std.experimental.  I originally thought that the difference between std.experimental and this library was going to be how it was used.

std.experimental:
   module that may become part of the standard libary later

your proposed library "mars"?:
   modules that will probably not become a part of the standard library.  They are "addons" to the standard library.  i.e. Maybe you would like the SDL library, but it doesn't make sense to include in the standard library because it it not useful to everyone.  For these kinds of libraries it would be nice to have a set of community supported libraries that shouldn't be in the standard library but are still useful to a subset of the community.

However, it appears that this proposal is just another version of std.experimental.

On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler wrote:
> This looks very similar to std.experimental.  I originally thought that the difference between std.experimental and this library was going to be how it was used.
>
> std.experimental:
>    module that may become part of the standard libary later
>
> your proposed library "mars"?:
>    modules that will probably not become a part of the standard library.  They are "addons" to the standard library.  i.e. Maybe you would like the SDL library, but it doesn't make sense to include in the standard library because it it not useful to everyone.  For these kinds of libraries it would be nice to have a set of community supported libraries that shouldn't be in the standard library but are still useful to a subset of the community.
>
> However, it appears that this proposal is just another version of std.experimental.

This is what I originally though as well. Personally I think what you just described would be much more useful. It really feels like this is just another std.experimental with only subtle distinctions. I don't think it adds much value.

On Thursday, 5 February 2015 at 04:37:21 UTC, Tofu Ninja wrote:
> On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler wrote:
>> This looks very similar to std.experimental.  I originally thought that the difference between std.experimental and this library was going to be how it was used.
>>
>> std.experimental:
>>   module that may become part of the standard libary later
>>
>> your proposed library "mars"?:
>>   modules that will probably not become a part of the standard library.  They are "addons" to the standard library.  i.e. Maybe you would like the SDL library, but it doesn't make sense to include in the standard library because it it not useful to everyone.  For these kinds of libraries it would be nice to have a set of community supported libraries that shouldn't be in the standard library but are still useful to a subset of the community.
>>
>> However, it appears that this proposal is just another version of std.experimental.
>
> This is what I originally though as well. Personally I think what you just described would be much more useful. It really feels like this is just another std.experimental with only subtle distinctions. I don't think it adds much value.


For me, this experimental thing is a problem due to the fact that release period of DMD is too long. Experimental means there will be lots of changes. A programmer shouldn't be waiting to get new versions of experimental codes.

What could be great is if DMD supported something like JAR packages, and could look for modules inside of them. So, all experimental codes would be packed daily in a zip file, and any programmer, with only download of a single file and including it on command line while compiling, would have latest code very quickly.

On Thursday, 5 February 2015 at 05:51:18 UTC, tcak wrote:
> On Thursday, 5 February 2015 at 04:37:21 UTC, Tofu Ninja wrote:
>> On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler wrote:
>>> This looks very similar to std.experimental.  I originally thought that the difference between std.experimental and this library was going to be how it was used.
>>>
>>> std.experimental:
>>>  module that may become part of the standard libary later
>>>
>>> your proposed library "mars"?:
>>>  modules that will probably not become a part of the standard library.  They are "addons" to the standard library.  i.e. Maybe you would like the SDL library, but it doesn't make sense to include in the standard library because it it not useful to everyone.  For these kinds of libraries it would be nice to have a set of community supported libraries that shouldn't be in the standard library but are still useful to a subset of the community.
>>>
>>> However, it appears that this proposal is just another version of std.experimental.
>>
>> This is what I originally though as well. Personally I think what you just described would be much more useful. It really feels like this is just another std.experimental with only subtle distinctions. I don't think it adds much value.
>
>
> For me, this experimental thing is a problem due to the fact that release period of DMD is too long. Experimental means there will be lots of changes. A programmer shouldn't be waiting to get new versions of experimental codes.
>
> What could be great is if DMD supported something like JAR packages, and could look for modules inside of them. So, all experimental codes would be packed daily in a zip file, and any programmer, with only download of a single file and including it on command line while compiling, would have latest code very quickly.

or std.experimental could just be separated into its own repository and put on dub?

You have clearly put a lot of effort in this. That makes me very uneasy to repeat the same critique as earlier but, sadly, it still all applies. This proposal tries to fix problems it doesn't prove exist, doing so with solutions that are not guranteed to help.

It also wrongly explains current process of inclusion into Phobos in general and specifically std.experimental - being probably one of more involved persons with Phobos review queue I feel like this needs to be explained.

Considering all the discussion that happened during std.experimental.logger I understand that we have settled with pretty much this:

1) All Phobos proposals must go through std.experimental.logger
2) It must implement something generally desired in Phobos
3) Implementation is supposed to be at least stable enough to not undergo a full rewrite after inclusion. Major API changes are acceptable.
4) Before DMD/Phobos release is made existing packages that feel stable can undergo a formal review for inclusion in Phobos main package

With that in mind initial public review is supposed to only determine if (2) and (3) is true which is mostly a formality as people rarely propose modules they are not serious about.

As you may see requirements are very lax. Only real difference is that your poposal allows to accept modules that are not supposed to ever go to Phobos at all - which I am still convinced is a bad thing and belongs to code.dlang.org

Speaking about objections vs code.dlang.org

> community driven development as opposed to individually driven (ownership/control of the source code)

see no reason to expect this is actually better of makes any notable difference in general

> out of the box readiness

dub is planned to be distributed with DMD

> wide range of community members involved in the development to reduce controversy and fragmentation staring from the initial stage

no idea where this even comes from

Pretty much all extra goodies from DIP73 can be implemented by creating special "officially endorsed" category in code.dlang.org and showing it as a default package list at code.dlang.org front page

In general, there needs to be a good analysis backing the proposal to change anything - good intention and good idea alone are not enough. It is better to do nothing than do something unless one is extremely sure that it will help.

On Thu, 05 Feb 2015 06:47:26 +0000, weaselcat wrote:

> or std.experimental could just be separated into its own repository and put on dub?

and make all rdmd users very unhappy, yeah. no, it's not about dub, it's about "std." prefix.

happy rdmd user.

On Wednesday, 4 February 2015 at 23:15:25 UTC, Jonathan Marler wrote:
> This looks very similar to std.experimental.

In one way, yes, it is similar to std.experimental, but not that much as it seems.

More precisely:

1. Take the namespace designed for new module drafting out of the Phobos
2. Put it in a separate library
3. Allow community common development from the beginning of the drafting stage
4. Propose Phobos inclusion when module is ready

> I originally thought that the difference between std.experimental and this library was going to be how it was used.
>
> std.experimental:
>    module that may become part of the standard libary later
>
> your proposed library "mars"?:
>    modules that will probably not become a part of the standard library.

Just small clarification.

Drafting library would include modules that are welcome to become a standard. The final decision about Phobos submission is made after standardization attempt failed, not before!

> They are "addons" to the standard library.  i.e. Maybe you would like the SDL library, but it doesn't make sense to include in the standard library because it it not useful to everyone.  For these kinds of libraries it would be nice to have a set of community supported libraries that shouldn't be in the standard library but are still useful to a subset of the community.

The DIP is defined in the spirit of what you originally thought.

1. If you want SDL (literaly) then use code.dlang.org package
2. If you want SDL like functionality then propose a new draft module (including gui functionality)

Piotrek

On Thursday, 5 February 2015 at 06:56:52 UTC, Dicebot wrote:
> You have clearly put a lot of effort in this. That makes me very uneasy to repeat the same critique as earlier but, sadly, it still all applies. This proposal tries to fix problems it doesn't prove exist, doing so with solutions that are not guranteed to help.
>
> It also wrongly explains current process of inclusion into Phobos in general and specifically std.experimental - being probably one of more involved persons with Phobos review queue I feel like this needs to be explained.
>
> Considering all the discussion that happened during std.experimental.logger I understand that we have settled with pretty much this:
>
> 1) All Phobos proposals must go through std.experimental.logger
> 2) It must implement something generally desired in Phobos
> 3) Implementation is supposed to be at least stable enough to not undergo a full rewrite after inclusion. Major API changes are acceptable.
> 4) Before DMD/Phobos release is made existing packages that feel stable can undergo a formal review for inclusion in Phobos main package

It seems to me that number 2 is wrong. It doesn't matter what is generally desired. The final say depends completely on the leadership. Yes or No has to come from above. Or am I wrong about this?

On Thursday, 5 February 2015 at 18:23:19 UTC, Zach the Mystic wrote:
> On Thursday, 5 February 2015 at 06:56:52 UTC, Dicebot wrote:
>> You have clearly put a lot of effort in this. That makes me very uneasy to repeat the same critique as earlier but, sadly, it still all applies. This proposal tries to fix problems it doesn't prove exist, doing so with solutions that are not guranteed to help.
>>
>> It also wrongly explains current process of inclusion into Phobos in general and specifically std.experimental - being probably one of more involved persons with Phobos review queue I feel like this needs to be explained.
>>
>> Considering all the discussion that happened during std.experimental.logger I understand that we have settled with pretty much this:
>>
>> 1) All Phobos proposals must go through std.experimental.logger
>> 2) It must implement something generally desired in Phobos
>> 3) Implementation is supposed to be at least stable enough to not undergo a full rewrite after inclusion. Major API changes are acceptable.
>> 4) Before DMD/Phobos release is made existing packages that feel stable can undergo a formal review for inclusion in Phobos main package
>
> It seems to me that number 2 is wrong. It doesn't matter what is generally desired. The final say depends completely on the leadership. Yes or No has to come from above. Or am I wrong about this?

Well there is a voting process for getting libraries accepted into Phobos, and Andrei and Walter are not the only ones who vote.  However, if you implement something that Andrei/Walter are strongly opposed to, I suppose the vote could be vetoed.