I don't use dub and I doubt I ever will.

As a ndslice user, I long dreaded this day:
2.074.0: "std.experimental.ndslice has been removed"

Well, I will deal with it, I was just thinking what could we do better for the future?

What if experimental was in a sub repo? Then everyone who gets a module accepted into experimental could get elevated access rights to the experimental module, since no other module should depend on an experimental module, it would be relatively safe, no? If this was the case maybe Ilya wouldn't have felt it was such a burden to maintain.

On Saturday, 25 March 2017 at 09:42:07 UTC, Daniel N wrote:
>
> As a ndslice user, I long dreaded this day:
> 2.074.0: "std.experimental.ndslice has been removed"

Are you aware that ndslice is available at https://github.com/libmir/mir-algorithm right?

I believe the reason std.experimental.ndslice must have been removed is because it was an already out of date fork. The newest is forked out of Phobos because the author decided to stop working inside Phobos. Maybe Ilya can explain it better if he sees the thread.

On Saturday, 25 March 2017 at 10:28:36 UTC, XavierAP wrote:
> On Saturday, 25 March 2017 at 09:42:07 UTC, Daniel N wrote:
>>
>> As a ndslice user, I long dreaded this day:
>> 2.074.0: "std.experimental.ndslice has been removed"
>
> Are you aware that ndslice is available at https://github.com/libmir/mir-algorithm right?
>
> I believe the reason std.experimental.ndslice must have been removed is because it was an already out of date fork. The newest is forked out of Phobos because the author decided to stop working inside Phobos. Maybe Ilya can explain it better if he sees the thread.

Well, as the guy who removed Mir from Phobos, I can share a couple insights on why having Mir in Phobos is problematic:

- different release cycle:
  - it takes minutes or hours for a bug fix in mir to be available and months for phobos
  - using proper semantic versioning deprecation issues are a greatly reduced (users always have the same code base and when they have time, they can upgrade to the latest and greatest)

- lack of progress:
  - there aren't many reviewers for ndslice, so in the past PRs to ndslice got unnecessarily stalled
  - there was a huge discussion last summer when Ilya tried to move ndslice.iteration into std.experimental.ndslice (there were endless discussions about the naming of his functions)

- dependency on LDC (fast math and previously proper FP math): mir wasn't compatible with DMD for a couple of releases
- external dependencies: e.g. mir-glas depends on a different cpuid than the one in core.cpuid
- Ilya has a huge focus on -betterC and the idea is that all Mir projects can be used without Phobos and druntime, so that it can easily be linked with C (see also his proposal for a small, modular and betterC-compatible standard library: https://forum.dlang.org/post/phexetutyelrssyrucvw@forum.dlang.org)

So in short: as long as a library is in active development, it's its death to put it into the standard library.

On 25/03/2017 3:20 PM, Seb wrote:
> On Saturday, 25 March 2017 at 10:28:36 UTC, XavierAP wrote:
>> On Saturday, 25 March 2017 at 09:42:07 UTC, Daniel N wrote:
>>>
>>> As a ndslice user, I long dreaded this day:
>>> 2.074.0: "std.experimental.ndslice has been removed"
>>
>> Are you aware that ndslice is available at
>> https://github.com/libmir/mir-algorithm right?
>>
>> I believe the reason std.experimental.ndslice must have been removed
>> is because it was an already out of date fork. The newest is forked
>> out of Phobos because the author decided to stop working inside
>> Phobos. Maybe Ilya can explain it better if he sees the thread.
>
> Well, as the guy who removed Mir from Phobos, I can share a couple
> insights on why having Mir in Phobos is problematic:
>
> - different release cycle:
>   - it takes minutes or hours for a bug fix in mir to be available and
> months for phobos
>   - using proper semantic versioning deprecation issues are a greatly
> reduced (users always have the same code base and when they have time,
> they can upgrade to the latest and greatest)
>
> - lack of progress:
>   - there aren't many reviewers for ndslice, so in the past PRs to
> ndslice got unnecessarily stalled
>   - there was a huge discussion last summer when Ilya tried to move
> ndslice.iteration into std.experimental.ndslice (there were endless
> discussions about the naming of his functions)
>
> - dependency on LDC (fast math and previously proper FP math): mir
> wasn't compatible with DMD for a couple of releases
> - external dependencies: e.g. mir-glas depends on a different cpuid than
> the one in core.cpuid
> - Ilya has a huge focus on -betterC and the idea is that all Mir
> projects can be used without Phobos and druntime, so that it can easily
> be linked with C (see also his proposal for a small, modular and
> betterC-compatible standard library:
> https://forum.dlang.org/post/phexetutyelrssyrucvw@forum.dlang.org)
>
> So in short: as long as a library is in active development, it's its
> death to put it into the standard library.

Or TLDR: it wasn't ready or appropriate for Phobos inclusion in the first place. But that was easier seen with hindsight sadly.

On Saturday, 25 March 2017 at 14:20:53 UTC, Seb wrote:
>
> So in short: as long as a library is in active development, it's its death to put it into the standard library.

That could be different for std.experimental.*? Or does that work only when development comes directly from the Foundation? Should it be different?

Nothing against having very useful and established libraries also outside Phobos, if it's more agile. If Boost had to be inside the C++ standard we would have never had Boost or C++11. I like to think Phobos is less rigid than C++ standard but still.

On Saturday, 25 March 2017 at 14:20:53 UTC, Seb wrote:
>
> https://forum.dlang.org/post/phexetutyelrssyrucvw@forum.dlang.org)

This has struck me from Ilya's post, as a problem that we had at my previous job: code base of old platform too monolithic, not modular enough; which in that case could turn "existing code base" into "legacy code base" too easily as soon as requirements need some flexibility:

On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko wrote:
>
> 3. Dependencies should be clear. Modularity is a proper way for large std library. In phobos everything integrated with everything. DRuntime -> Phobos abstraction is weird for betterC because system modules can depends universal algorithms, but universal algorithm are more portable if they have not system dependencies.

Now I am aware this case is very different. A standard library, specially excluding std.experimental, should have very stable requirements, and it's ok to make everything depend on all of it because it's supposed to stay. But in the past I've argued[1] that D needs for commercial success a much broader standard library than std or the C++ parallel STL, emulating the more modern examples (not regarding language design but just functionality) of Java, Python or .NET.

So I guess what I mean is that for me "std" would be "core", "core" would be "core.core", and I think D should work towards establishing and offer many other different modules, either as part of the standard library, or de facto standard (e.g. vibe, mir... gui??). But this is off topic and unfortunately far into the future. And then in this situation these additional modules could depend on the existing std, but not among each other.


[1] http://forum.dlang.org/post/vzgxlcfxfxzdezrfxicr@forum.dlang.org

On Saturday, 25 March 2017 at 16:50:18 UTC, XavierAP wrote:
> On Saturday, 25 March 2017 at 14:20:53 UTC, Seb wrote:
>>
>> So in short: as long as a library is in active development, it's its death to put it into the standard library.
>
> That could be different for std.experimental.*? Or does that work only when development comes directly from the Foundation? Should it be different?
>

That was kinda what I was hoping, there could be a 2nd bikeshedding/review before graduating out of experimental, but allowing the author to get some work done during the experimental phase.

> Nothing against having very useful and established libraries also outside Phobos, if it's more agile. If Boost had to be inside the C++ standard we would have never had Boost or C++11. I like to think Phobos is less rigid than C++ standard but still.

If there's 1 big library that's fine, but if you have to puzzle together 5 small ones...

On Saturday, 25 March 2017 at 10:28:36 UTC, XavierAP wrote:
> On Saturday, 25 March 2017 at 09:42:07 UTC, Daniel N wrote:
>>
>> As a ndslice user, I long dreaded this day:
>> 2.074.0: "std.experimental.ndslice has been removed"
>
> Are you aware that ndslice is available at https://github.com/libmir/mir-algorithm right?

yes, thanks.