On Sunday, 1 February 2015 at 22:54:51 UTC, Piotrek wrote:
On Sunday, 1 February 2015 at 21:54:13 UTC, Dicebot wrote:
1) what would it give over std.experimental ?
- draft modules will be more flexible for changes than in the
ones in standard library
- new drafting modules won't disturb usual users of the
standard library
IMO, std.experimental is not for the drafting stage of the SW
development.
I don't see the return on investment for making a big distinction
between a draft and a more polished, but still not guaranteed
library. The big line that needs to be drawn is whether any given
task is or is not an appropriate target for the standard library.
Once something passes that stage, it needs to be decided whether
the API is in flux (e.g. std.experimental) or stable (e.g. std
proper). An additional distinction between "more in flux" (your
idea) and "less in flux" (std.experimental) is both less useful
and quite possibly dangerous:
The big temptation for software developers is to *promise*
stability in order to attract the users they need in order to get
the feedback they need in order to create the best possible
design, and then break stability with the new design. By dividing
libraries into the hazy "more in flux" and "less in flux"
categories, one is simply deferring the hard choice between
"stable" and "not stable", and likely to start making promises
one cannot -- or worse, does not even intend to -- keep as a
result.
Therefore, I think std.experimental is for all "in flux" APIs,
from the drafting stage to the later "less in flux" stages. The
danger is that the phobos management will want to have their cake
and eat it too, as the saying goes. You simply can't promise
users both stability and a perfectly designed API at the same
time, tempting as it is.
