On Saturday, 23 April 2016 at 09:57:20 UTC, Ilya Yaroshenko wrote:
On Friday, 22 April 2016 at 22:11:27 UTC, Joseph Rushton
Wakeling wrote:
On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko
wrote:
On Sunday, 17 April 2016 at 08:49:53 UTC, Seb wrote:
On Sunday, 17 April 2016 at 07:35:19 UTC, Ilya Yaroshenko
wrote:
[...]
Another idea would be to go with std.experimental.sci.*, if
that has a higher consensus.
Just with std.sci.* without `experimental`. Otherwise this
would be the same problem.
Why ... ? Just keep everything in std.experimental.sci until
all the details are worked out, and only transition to std.sci
in one go once it's all done.
3-5 years... And then switch to D3.
I don't really see the analogy.
If we go your sci.* route, or std.sci.*, then the module naming
suggests stability, and things require explicit documentation as
experimental -- and the downstream user has to deal with the
mental burden of unpicking what is not actually stabilized and
reliable.
If we go with std.experimental.sci.*, then the module naming
explicitly documents that the package as a whole is _not_
stabilized. You can document modules that _are_ considered as
stable and reliable, and in doing so you're making a clearer
promise to the downstream user.
You could also move stable std.experimental.sci modules to
std.sci while providing deprecated public imports in the old
std.experimental.sci module, and those could be maintained for
the entire lifetime of std.experimental.sci (i.e. until the
entire package is stabilized). So again, downstream users would
only have to pay the full price of a breaking change once.
