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.
