Mars Drafting Library - Official community driven library

[Piotrek via Digitalmars-d]

On Sunday, 1 February 2015 at 23:21:36 UTC, Dicebot wrote:
> As per latest agreement everything in std.experimental is 
> considered subject to any change so is perfectly flexible.
>



>> - new drafting modules won't disturb usual users of the 
>> standard library
>
> That statements needs some hard data that current situation is 
> disturbing to be considered as a rationale.

If you put to many uncompleted modules in the std.experimental it 
can influence stable part of the Phobos.

- binary size
- pull request with more experimental stuff
etc.

>> IMO, std.experimental is not for the drafting stage of the SW 
>> development.
>
> Depends on your definition of "draft". Anything that is good 
> enough to be actually used in real app is good enough for 
> std.experimental - and anything less is of no use to end user 
> anyway.

I agree that all is a matter of definition. I still doubt that 
fast evolving drafts would be possible in std namespace.

>>> 2) what would it give over code.dlang.org ?
>>
>> - community driven as opposed to individual driven
>> - out of the box readiness
>> - minimal fragmentation and controversy
>
> code.dlang.org is actually much more community driven because 
> it is naturally decentralized. Controversy is inevitable anyway 
> (hello std.json).

I used the "community driven" in contrast to "individually 
driven". The key property of the proposal is to minimize the 
controversy by community (common) drafting process.

> Fragmentation is a thing though - but I yet to be convinced 
> that is a bad thing that needs to be fixed.

I consider fragmentation a major problem for standards.

>>> 3) what problems are you trying to solve and why do you think 
>>> this is suitable solution?
>>
>> Adding new modules (replacing the deprecated ones) in more 
>> robust and quicker manner.
>
> It is as quick as it can be for standard library - and 
> code.dlang.org takes care of everything else.

I have non-trivial modules in mind like gui, json, database, etc.

> Any library that risks quick removal of deprecated modules / 
> API is not acceptable for "standard" stamp.


The drafting lib is a proposition of standard not a standard 
itself.
And I didn't said anything about removal. I was referring to:

"Warning: This module is considered out-dated and not up to 
Phobos' current standards. It will remain until we have a 
suitable replacement, but be aware that it will not remain long 
term."

> So far this does not seem a proposal that pulls own weight to 
> me.

I can put the burden on my shoulders.

I'm in the middle of DIP creation. Unfortunately I have a regular 
job and other duties. Still, I hope to finish it as soon as 
promised.

Piotrek