stc.experimental.ndslice -> sci.ndslice

[Joseph Rushton Wakeling via Digitalmars-d]

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.