Official stdx

barryharris slackovsky at gmail.com
Sat Oct 5 05:12:26 PDT 2013


On Saturday, 5 October 2013 at 01:53:13 UTC, Jesse Phillips wrote:
> On Friday, 4 October 2013 at 10:02:21 UTC, John Colvin wrote:
>> I would imagine a compulsory waiting period of the order of 
>> months, combined with a requirement of evidence that the 
>> module has been effective in the real world and that any 
>> outstanding problems have been resolved appropriately**.
>
> I think this requirement is unobtainable. You're basically 
> saying, "Hey go use this in your real world applications. We've 
> got a mandated break of that application, just don't know when 
> that is. But totally use this like you can rely on it."
>
> I know it is really nice to have these test libraries released 
> with the compiler, but people really just need to go out and 
> use these libraries before the inclusion. I'm guilty too. I had 
> use for std.uuid, but didn't test it against my real code. It 
> went through review and even after inclusion I was still using 
> the basic generator I created from an RFC doc. I've since made 
> the switch, but I didn't do it because a review needed my help.
>
> I think a stdx could be beneficial in our current state but I 
> think it should be temporary. One maybe two years. The timing 
> for move should be clear, accepted => stdx => next release => 
> std.

I quite like the idea of a stdx and imagine it to be similar to 
what we have in boost for C++.

A set of high quality, peer-reviewed libraries that are worthy of 
Phobos but haven't yet had enough real-world testing to be 
accepted into Phobos proper. Hopefully the peer-review process 
would include core Phobos developers to ensure the D-essence and 
quality is maintained throughout.

> I think a stdx could be beneficial in our current state but I 
> think it should be temporary. One maybe two years. The timing 
> for move should be clear, accepted => stdx => next release => 
> std.

I agree partially with this. Once a library is flagged for Phobos 
from stdx it has to have a consistent and set migration path. But 
I don't think all stdx libraries need to be Phobos targets. For 
example, I don't think Phobos needs a CSV reader module, nor 
std.net.curl, even though both are very useful. Opt-in stdx 
modules via the official dub package manager would be a good 
option, allowing Phobos proper to remain small and light as 
possible.

G.


More information about the Digitalmars-d mailing list