Mars Drafting Library - Official community driven library

[Zach the Mystic via Digitalmars-d]

On Sunday, 1 February 2015 at 22:54:51 UTC, Piotrek wrote:
> On Sunday, 1 February 2015 at 21:54:13 UTC, Dicebot wrote:
>> 1) what would it give over std.experimental ?
>
> - draft modules will be more flexible for changes than in the 
> ones in standard library
> - new drafting modules won't disturb usual users of the 
> standard library
>
> IMO, std.experimental is not for the drafting stage of the SW 
> development.

I don't see the return on investment for making a big distinction 
between a draft and a more polished, but still not guaranteed 
library. The big line that needs to be drawn is whether any given 
task is or is not an appropriate target for the standard library. 
Once something passes that stage, it needs to be decided whether 
the API is in flux (e.g. std.experimental) or stable (e.g. std 
proper). An additional distinction between "more in flux" (your 
idea) and "less in flux" (std.experimental) is both less useful 
and quite possibly dangerous:

The big temptation for software developers is to *promise* 
stability in order to attract the users they need in order to get 
the feedback they need in order to create the best possible 
design, and then break stability with the new design. By dividing 
libraries into the hazy "more in flux" and "less in flux" 
categories, one is simply deferring the hard choice between 
"stable" and "not stable", and likely to start making promises 
one cannot -- or worse, does not even intend to -- keep as a 
result.

Therefore, I think std.experimental is for all "in flux" APIs, 
from the drafting stage to the later "less in flux" stages. The 
danger is that the phobos management will want to have their cake 
and eat it too, as the saying goes. You simply can't promise 
users both stability and a perfectly designed API at the same 
time, tempting as it is.