Adding new (or replacement) phobos modules without wider testing
is not a scalable approach for D.
New modules go from unofficial to official in a single step and
are therefore inadequately battle-tested before becoming part of
the somewhat ossified environment of a standard library.
Assertions:
1) In the current situation, modules go from independent projects
to becoming official parts of phobos at a single point. It's a
binary switch.
2) New modules, in the form proposed for submission, are fully
read through by a small number of people.
3) New modules, in the form proposed for submission, have often
been seriously used by only an even smaller number of people.
4) Breaking changes to phobos are currently undesirable.
Argument:
Due to the combination of 1,2 and 3, we unwittingly introduce
bugs and poor design decisions in to the standard library, with
all the inflexibility that entails. Due to 4 we then either
cannot or do not fix these problems in an optimal fashion, if at
all. We can do better.
Necessary Solution:
People need to really use these new modules before they are
pulled in to phobos. In particular, the API must be stress tested
in a variety of situations.*
Implementation:
In the current situation all the code is public, so people are
totally free to try out the proposed modules and test them. They
don't and they won't.
I propose that the current review process be redirected to a new
target package in the phobos repo, stdx, which would then have a
separate review process for inclusion in std.
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**. Stdx would make no
explicit promises about API stability, but modules would be
considered as semi-finished products; Revisions that effectively
amount to a significant rewrite (in particular to the API) would
require re-submission for initial review.
Stdx would occupy a space between phobos and unaffiliated
packages, allowing for subtle (i.e. missed during initial review)
but critical problems requiring breakage to be identified BEFORE
inclusion in the standard library proper. I believe providing
this official stepping stone for new modules will result in
significantly wider usage and testing, benefiting phobos, D and
it's community.
*API design is *hard*. Knowing what is a good decision ahead of
time is a matter of experience.
** The appropriate action may be to not fix it. There are always
trade-offs.
P.S.
I am aware that this is not a new idea at all. I thought it was
worth presenting with a clean slate.
