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