Official stdx

John Colvin john.loughran.colvin at gmail.com
Fri Oct 4 03:02:20 PDT 2013


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.


More information about the Digitalmars-d mailing list