Mars Drafting Library - Official community driven library

[Piotrek via Digitalmars-d]

On Monday, 2 February 2015 at 21:19:01 UTC, Zach the Mystic wrote:

> I think std.experimental should essentially be its own library, 
> with its own slot next to phobos on the github repo. I'm open 
> to changing the name or something... but if we have both 
> std.experimental *and* your new mars, what do you think is the 
> real difference? How can std.experimental be "sort of" 
> experimental, but really not, whereas mars is "really actually" 
> experimental? Where is the cutoff line? How would anyone know 
> whether they reached it or not?

Hard to admit but I thought about removal of std.experimental ;), 
then I tried to find a better solution (not sure I did). After 
all I don't want to make more enemies than I have.

So I got an idea that std.experimental can be adopted for the 
piloting new modules into Phobos when approved to be a standard.

After Wikipedia:
"A pilot project refers to an initial roll-out of a system into 
production"

> My attitude is that any given module in std.experimental should 
> simply indicate its current level stability at the top of its 
> documentation - full disclosure about where it is from, say, 0 
> to 95%, (with anything above that already assumed qualified for 
> std proper).

Yes, the drafting stage can have many sub-stages, but I didn't 
want to complicate the initial proposal too much and risk both 
low chance of the approval and later, inability of proper 
implementation. I learned that there can be taken only limited 
steps at once.

> I'd even make one more point, that all current phobos modules 
> known to be in need of revamping be copied wholesale in their 
> current forms to std.experimental, with the top documentation 
> saying, "This is the experimental version of the old std.xxx, 
> which needs *your* help with its redesign and implementation. 
> Feel free to break the current API by improving it. This is 
> *not* currently considered a stable module."

Haha, let's not lose our nerves :) It's not that bad. Moreover. I 
can barely find  the equivalent level of code awesomeness as it 
is in D libraries. We just need to speed up the progress and 
reduce work fragmentation.

Piotrek