std.experimental repo

[XavierAP via Digitalmars-d]

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