On Sunday, 17 April 2016 at 09:32:25 UTC, QAston wrote:
> On Sunday, 17 April 2016 at 09:09:52 UTC, Ilya Yaroshenko wrote:
>>
>> Just with std.sci.* without `experimental`. Otherwise this would be the same problem.
>
> What's wrong with std.experimental.sci.*? experimental is where experimental modules/packages should go.

This would be a real pain for a user if he supports few compiler versions.


static if(__VERSION__ < 2072)
{
	import std.experimental.sci.ndslice;
}
else
{
	import std.sci.ndslice;
}

static if(__VERSION__ < 2074)
{
	import std.experimental.sci.fft;
}
else
{
	import std.sci.fft;
}


static if(__VERSION__ < 2075)
{
	import std.experimental.sci.blas;
}
else
{
	import std.sci.blas;
}

static if(__VERSION__ < 2076)
{
	import std.experimental.sci.lapack;
}
else
{
	import std.sci.lapack;
}

On 17.04.2016 11:44, Ilya Yaroshenko wrote:
> This would be a real pain for a user if he supports few compiler versions.
>
>
> static if(__VERSION__ < 2072)
> {
>      import std.experimental.sci.ndslice;
> }
> else
> {
>      import std.sci.ndslice;
> }
[...]

Breakage is what you sign up for when using experimental modules.

However, when std.experimental.foo moves over to std.foo, it's probably possible to keep the experimental name as an alias for the new one. That way you just import std.experimental.foo until a reasonable amount of past versions have std.foo. That's how it went with std.typetuple -> std.meta.

ndslice should move out of experimental when it's ready, not sooner. If this hinders the creation of other std modules, then push for ndslice to get ready.

On Sunday, 17 April 2016 at 09:44:30 UTC, Ilya Yaroshenko wrote:
> This would be a real pain for a user if he supports few compiler versions.

This approach is wrong because you assume there won't be changes to how module works while in experimental and during transition from experimental to stable. There will be changes, so supporting older compiler versions like that is just asking for bugs. Module name change is there so that you won't be using broken api by mistake.

Instead you should do the following:
-develop experimental module in std.experimental.sci.*
-do breaking changes to those modules during several release cycles
-when module reaches stability move the module to std.sci.*; and create a polyfill package for it inside dub registry, like https://code.dlang.org/packages/experimental_allocator , so that older compilers can use the latest std.sci.* module instead of broken std.experimental.sci.* shipped with old compiler.

On 04/17/2016 09:10 AM, Ilya Yaroshenko wrote:
> We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.
> 
> 
> https://github.com/dlang/phobos/pull/4207

This is a good example of why using a dedicated dub category is completely superior to std.experimental

On 4/17/16 6:04 AM, ag0aep6g wrote:
> On 17.04.2016 11:44, Ilya Yaroshenko wrote:
>> This would be a real pain for a user if he supports few compiler
>> versions.
>>
>>
>> static if(__VERSION__ < 2072)
>> {
>>      import std.experimental.sci.ndslice;
>> }
>> else
>> {
>>      import std.sci.ndslice;
>> }
> [...]
>
> Breakage is what you sign up for when using experimental modules.
>
> However, when std.experimental.foo moves over to std.foo, it's probably
> possible to keep the experimental name as an alias for the new one. That
> way you just import std.experimental.foo until a reasonable amount of
> past versions have std.foo. That's how it went with std.typetuple ->
> std.meta.

Yes. In cases of moving code from std.experimental to main package (I don't think this has happened yet), we can leave a public re-import in std.experiemental for several releases before removing.

And we should remove it. It should not be standard to allow import std.experimental when it has been moved to std.

-Steve

On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
> We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.
>
>
> https://github.com/dlang/phobos/pull/4207

As I have said many times on both IRC and NG, I would prefer to have `stdx` instead of ridiculously long (4x) `std.experimental`. Then you would have a nice package named `stdx.sci`.

PS. this is not my "invention" - Java community has `javax` for similar (but different, as nothing in javax is experimental) purpose!

On Monday, 18 April 2016 at 16:13:54 UTC, Dejan Lekic wrote:
>
> As I have said many times on both IRC and NG, I would prefer to have `stdx` instead of ridiculously long (4x) `std.experimental`. Then you would have a nice package named `stdx.sci`.

Fantastic idea (that I had not heard before).

On Monday, 18 April 2016 at 16:13:54 UTC, Dejan Lekic wrote:
> As I have said many times on both IRC and NG, I would prefer to have `stdx` instead of ridiculously long (4x) `std.experimental`. Then you would have a nice package named `stdx.sci`.

How often are you typing in import statements that their length becomes a problem?

On 4/18/16 12:13 PM, Dejan Lekic wrote:
> On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
>> We plan to add a set of numeric packages and this would be real pain
>> if they would be one-by-one moved from experimental to stable std. So
>> sci.* should be considered as experimental during few years.
>>
>>
>> https://github.com/dlang/phobos/pull/4207
>
> As I have said many times on both IRC and NG, I would prefer to have
> `stdx` instead of ridiculously long (4x) `std.experimental`. Then you
> would have a nice package named `stdx.sci`.
>
> PS. this is not my "invention" - Java community has `javax` for similar
> (but different, as nothing in javax is experimental) purpose!

javax, and its history and vagueness, is exactly why we have std.experimental. std.exp was also proposed, but rejected because it's not obvious what it means.

See, for instance, javax.swing, which was supposed to be promoted to java package, but produced a huge backlash for people who were going to have to modify their imports.

The idea is to spell out "expect breakage here, this module is experimental". If you don't know what this means, then that's too bad. But you can't complain that we didn't warn you :)

-Steve

On Sunday, 17 April 2016 at 06:10:34 UTC, Ilya Yaroshenko wrote:
> We plan to add a set of numeric packages and this would be real pain if they would be one-by-one moved from experimental to stable std. So sci.* should be considered as experimental during few years.
>
>
> https://github.com/dlang/phobos/pull/4207

sci as in ?

If it is as in science, please just name this science. We have terabytes of hard drive, we can do with 4 extra characters.