Mars Drafting Library - Official community driven library

[Zach the Mystic via Digitalmars-d]

On Monday, 2 February 2015 at 22:18:59 UTC, Piotrek wrote:
> 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.

I'm arguing from the perspective that the approval must come 
first, and the piloting second. Who would want to develop a 
module in the "pre-pilot" phase, without having any idea of 
whether they were developing it finally for phobos or just 
3rd-party use, then wait months or years to find out if the 
leadership is even *interested* in what they're doing? Why would 
people try to meet high standards without knowing if those 
standards are actually going to be required or not? It's like an 
unpaid internship: "Work for us for free, and we'll let you know 
at the end whether we want your work or not."

>> 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.

It occurred to me that when copying a module to std.experimental, 
the documentation at the top of the original std module should 
say, "This module has been feature frozen while work on the new 
one continues at std.experimental.xxxx. The API for this module 
will not break, nor will it be improved. Please consider using 
std.experimental.xxxx and giving feedback for its design, since 
eventually this module will be replaced with that one."

I do realize that this is kind of what happened with D1 and D2, 
of course. Now you're going to have competing modules, and some 
people won't want to give up on the old one. So you will have to 
deprecate every change that breaks the old API first before 
finally replacing it with the new one. Well, it's a hard problem, 
and yet, "Most D code has yet to be written." But then again, I'm 
not the one who has to take fire for breaking people's old code, 
and I don't know if my attitude would change if I were.