On Sunday, 18 December 2016 at 15:18:37 UTC, Andrei Alexandrescu wrote:
> On 12/18/16 4:26 AM, Ilya Yaroshenko wrote:
>> Hi,
>>
>> Who is interested in betterC _modular_* standard library?
>> I am planing to make libmir org a community for it.
>> Thought and concerns?
>>
>> We already have better `cpuid` and better `random` packages. The betterC
>> std.range and std.algorithm analogs would be released with new ndslice
>> implementation. Mir's algorithm would be faster then Phobos and will
>> generate less template bloat. Then lightweight threads, multithread
>> GLAS, matrix inversion. Fastest I/O and http2 ...
>>
>> (they all are betterC modular libraries)
>>
>> Andrei and probably 90% of existing D users don't want Phobos to move
>> this direction.
>
> Please do not misconstrue what I said.
>
> You have my support to improve the state of affairs with the D core runtime and standard library, and have had it from day one.
>
> With regard to new functionality that supplants existing pieces such as cpuid_v2 or random_v2, definitely. We can and should add that and many other great things to phobos. Go for it.
>
> With regard to avoiding to link druntime, we should build the argument better. Is all of druntime bad, or just parts of it?

DRuntime is good for applications. But writing multi-language libraries with DRuntime is bad idea. The last paragraph in [1] describes why DRuntime can not be used for GLAS.

I never said we should "remove GC" or "remove runtime". We just need to provide a clear way for betterC subset and modularise library. DRuntime and Phobos are well designed hight level libraries.

> E.g. if something does not link the GC but does use vtables, is it good/bad, and to what extent?

Very good point. First, I don't see a real reason why we need DRuntime for vtables (classes and interfaces). LDC allows to use vtables without DRuntime (only with extern(C++), hehe). D classes can be constructed on stack or with allocators. The only problem is vtable initlization, which requires `typeid` (TypeInfo object). I am not a OOP expert, but it looks like we can have extern(C++) classes without DRuntime if we solve problem with initilization.

> These issues are not entirely clear to me and it would be great if you explained them better. I definitely need to be better educated on this. What I do know is making "don't use druntime" a goal in and of itself is not the most useful way to frame the problem.

0. Linking compatibility. Assume A has builded a betterC library AA using GDC version XXX and B has builded a betterC library BB using LDC version YYY.

Question: how mister C can use BB and AA together in his C-library if both this libraries depends on different DRuntimes (compiler and version)?

1. Different mangling names for DMD and LDC. mir-cpuid provides extern(C) interface for all functionality except few very low level struct declarations. The general problem is that we do not have binary compatibility where we may have it. And it is not clear where we already have it.

2. Any function may throw an Error.

3. Any throwable is not a part of betterC. Phobos core team rejected approach to replace RangeErrors with asserts or another function declaration. Possible alternative is __range_assert() or a library function.

4. Threads are GC oriented:
    1. They are classes (they can be structs like allocators)
    2. They are integrated with GC. This requires additional computation time if I am not wrong.
    3. They are not replaceable. Phobos multithread modules can not use something else.

5. Mutexes are GC oriented:
   ditto 1. and 3.

6. Intrinsics are compiler magic without specification. It is not clear what it is intrinsic, are they inlined, where their bodies are defined, how/if they works in CTFE. LLVM provides a list of intrinsics [3], this is very useful to write a betterC libraries.

... and many other ... They all are not clear for me too.

-------------
A solution for mister C:
Mister A and mister B should use a runtime which has either a small stable extern(C) interface or all its functions are inlined. All other functions can be a dub packages.
-------------

Proof:
cpuid: extern(C) interface with aliases.
a fork of aligned  mallocator for GLAS: all functions are always inlined.

> With regard to changes that break the entire fabric of Phobos (such as: we must eliminate random-access ranges), this is definitely more like simple survival rather than things I want.

I don't want eliminate R-A-R now. But we can change our Range concept and provide alternative module as dub package, which will be announced as a future replacement (say, after 5 years). But duplicated sorting implementation with cursors (lightweight iterators) in the same module is weird. It is better to continue this discussion after the cursor based implementation will be ready for your review.

> With regard to properly attributing credit for good work, I believe this is important and I commit to do anything reasonable for making it happen.
>
> I kindly advise you to better understand what you are trying to do, and how to do it to maximize impact. It seems you are not entirely clear on what you want to do and what the best route is, as shown by you retiring your std.experimental.ndslice work after you've had full freedom on what should go in it.
>
>> In other hand I need a commercial attractive D infrastructure for large
>> and heavy system projects. There is no commercial perspective for me to
>> contribute to Phobos because:
>>
>> 1. Phobos version depends on compiler version. Delay with LDC release is
>> too large. It should / can be one day.
>
> Then a good way to help this is improve the LDC lag.

I mean lag between new Phobos PR and LDC release. This includes time for PR review, DMD release, LDC release. Libraries should be separated from a compiler, IMHO.

>> 2. We can not do hot fixes in Phobos without compiling and deploying
>> patched libphobos. Mir's DUB package are much more flexible.
>
> The reverse of that is less stability.

A hot fix can be added in local repository without creating a PR. DUB allows to do it.

> The good part about merging your work in Phobos is you maximize impact and visibility.

Yes, but merging existing libraries to Phobos will slowdown other projects as DCV. Also  I will spend a lot efforts on stuff like repositories synchronisation. Plus it makes my users unhappy: they will need to switch from Phobos to Mir if they want to use recent addition.

> These seem to me artificial arguments. Yes, being preoccupied over quick deployment may make sense in the initial stages when there's no stability and the design may take any direction. That should get less necessary once some abstractions are in place.

C++ adds new APIs one time per few years. D add few changes every month.

Phobos and DRuntime does not behave as traditional standard system language libraries. They are more like a scripting language heaps which are grows very fast (like scipy).

I wan't a D Standard Library to be exist too, but it should be slim, has better backward compatibility, ideal backward binary compatibility, has good low level specification and documentation. Large hight level library like Phobos can not do it with community support only.

> Organizations that are interested in patching minute fixes may build their own standard library (and sometimes compiler). This is routinely the case with C++ at Facebook, Google, and in all likelihood other large-scale tech shops. It would be tenuous to argue that this should be the default way to go about things for everyone. I don't understand why you consider it an essential matter.

Good point. Why not to be more user friendly for large-scale tech companies then?

If we can show that merging too LDC requires less efforts then upgrading from g++ to clang++ ...

>> 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.
>
> I read this three times and cannot understand it. At any rate: DIP 1005, which is partially motivated by our discussions, should allow us to make dependencies as simple and clean as function-level.

The  DIP 1005 idea is good. But this will fix few percentage of existing dependency ambiguity. Plus it does not solve the dependency problem, it just makes it slightly more visible.

>> 4. Phobos does not provide and will not provide betterC guaranties. If
>> something works for betterC mode now it may not work in the future release.
>
> Yes, we can definitely improve this.
>
> We (the Foundation) are all for making things better for achieving the things you want to achieve. At this point D needs unity and rallying under a shared vision, not balkanization in several special interest groups. There are so many great things you can do starting literally today to make things better for everybody using D, and why in the world would anyone want to stop you. I strongly believe your participation to the Standard D language and library will be vastly better for you personally and professionally.
>
>
> Andrei

I will continue in the answer to Walter.

Thank you for the answer (it is hard to understand me because English and other reasons),

Ilya

[1] http://forum.dlang.org/post/jwmzvfashovivqzamxrq@forum.dlang.org
[2] http://forum.dlang.org/post/jneokbosxeatvkppbuvf@forum.dlang.org
[3] http://llvm.org/docs/LangRef.html#intrinsic-functions

On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright wrote:
> On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote:
>> We already have better `cpuid` and better `random` packages.
>
> Great! Please PR them for Phobos.

cpuid is used in Mir GLAS and it should be a betterC library. Without DRuntime dependency because DRuntime has not backward binary compatibility and has not compatibility between different compilers.

From my reply to Andrei:

----
Linking compatibility. Assume A has builded a betterC library AA using GDC version XXX and B has builded a betterC library BB using LDC version YYY.

Question: how mister C can use BB and AA together in his C-library if both this libraries depends on different DRuntimes (compiler and version)?
----

mir-glas and mir-cpuid are libraries with extern(C) interface for all languages. It is silly to build a BLAS implementation only for one language.

>> The betterC
>> std.range and std.algorithm analogs would be released with new ndslice
>> implementation. Mir's algorithm would be faster then Phobos and will generate
>> less template bloat. Then lightweight threads, multithread GLAS, matrix
>> inversion. Fastest I/O and http2 ...
>>
>> (they all are betterC modular libraries)
>
> Propose them for Phobos!

First I need to implement them and announce for the community. Then community will say "What he is doing??? C++ iterators, really?" Hehe

This is reason why ndslice is deprecated in Phobos. It requires another std.algorithm and std.range. I am not able to implement all this ideas in Phobos PRs: it is requires too much time. In addition, I can not use Phobos for other reasons.

>> Andrei and probably 90% of existing D users don't want Phobos to move this
>> direction.
>
> I don't understand that point. What direction?

1. Modularity: D should provide a very slim library (like std.traits and may be default GC with old core, which can be turned off or replaced). Other parts or Phobos/Druntime should be split into parts and the parts should have their own repositories. They should be dub packages with D Foundation review / control.

2. Low-level API first! A high level OOP/GC-oriented API can be provided later or can be provided in DUB libraries.

3. betterC guaranties / No problems with backward binary compatibility for betterC libs. This means that code should be templated / inlined. Some parts, like Exceptions and GC may have this problems, but Exceptions and GC should be optional language features and they are not a part of betterC mode.

>> In other hand I need a commercial attractive D infrastructure for large and
>> heavy system projects. There is no commercial perspective for me to contribute
>> to Phobos because:
>>
>> 1. Phobos version depends on compiler version. Delay with LDC release is too
>> large. It should / can be one day.
>
> The language evolves over time, and the standard library must, too. It happens with every language.

Agreed. Because that it is more flexible to have a very slim std library with good set of community supported libraries.

This is a reason why almost all portable multi-language numeric libraries are written in C. C runtime is slim and evaluates very-very slow.

>> 2. We can not do hot fixes in Phobos without compiling and deploying patched
>> libphobos. Mir's DUB package are much more flexible.
>>
>> 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.
>
> Not sure what you mean. Algorithms in Phobos are not dependent on system idiosyncracies.

They are, for example they depends on RangeErrors. See
https://github.com/dlang/phobos/pull/4937

>> 4. Phobos does not provide and will not provide betterC guaranties. If something
>> works for betterC mode now it may not work in the future release.
>
> I've done a fair amount of work to remove such things. Clearly more can and should be done.
>
> Generally, we do have a goal of making Phobos entirely "pay as you go" instead of being so interconnected (which is what betterC is really all about). We can definitely use help in improving that and helping it along.

Great. Why not to go to the proposed direction:
    1 Modularity,
    2 Low-level API first,
    3 betterC guaranties?

Thank you,
Ilya

On Sunday, 18 December 2016 at 14:37:55 UTC, Radu wrote:
> On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko
>> Who is interested in betterC _modular_* standard library?
>> I am planing to make libmir org a community for it.
>> Thought and concerns?
>
> I hope this doesn't turn into a new Tango vs. Phobos war.

My first thought as well. Probably an irrational fear, but the question will pop up often.

On 12/18/2016 01:49 PM, Ilya Yaroshenko wrote:
> On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright wrote:
>> On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote:
>>> We already have better `cpuid` and better `random` packages.
>>
>> Great! Please PR them for Phobos.
>
> cpuid is used in Mir GLAS and it should be a betterC library.

It's this kind of imaginary dialog that I don't quite grok:

Ilya Yaroshenko: "I can't use druntime's cpuid so I defined my own."

Andrei Alexandrescu: "OK, so what's different?"

IY: "Mine has a few engineering improvements."

AA: "Cool, why don't you merge them into core.cpuid?"

IY: "Well mine doesn't have a shared static constructor, so it doesn't need a runtime to automatically call that library initialization function. User need to explicitly call an init function before using it."

AA: "I understand. Great, so how about this - we add your code to core.cpuid_v2 to druntime. Then we make all in core.cpuid to forward to it so there's no duplication. It all works out!"

IY: "No, I don't want to do that. It's still in druntime and I don't want druntime. I want betterC."

AA: "But it will be compilable with betterC and we can add unittests to make that happen. YOU HAVE MY SUPPORT. Let's do it."

IY: "No, I want to change it often. The deployment schedule of druntime is too slow."

AA: "How often do you need to change it? Is it that unstable?"

IY: "Um, not too often."

AA: "Then what is the matter? Are you worried about the IP of the engineering improvements you are making? Are you licensing this differently?"

IY: "No, it's for the most part similar to core.cpuid and the license will be also Boost."

AA: "Then what is the matter? Do you want me to wait until you release a stable mir.cpuid and copy it over with credit, per the Boost license, to core.cpuid_v2?"

IY: "..."

It's this kind of stuff I need to have a better understanding of. Some technical arguments are meaningful, some others point to problems with obvious solutions that are somehow shunned, and yet others are like a hidden Markov model - I see the effects, but I don't see the causes.


Andrei

On Sunday, 18 December 2016 at 19:28:24 UTC, Andrei Alexandrescu wrote:
> On 12/18/2016 01:49 PM, Ilya Yaroshenko wrote:
>> On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright wrote:
>>> On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote:
>>>> We already have better `cpuid` and better `random` packages.
>>>
>>> Great! Please PR them for Phobos.
>>
>> cpuid is used in Mir GLAS and it should be a betterC library.
>
> It's this kind of imaginary dialog that I don't quite grok:
>
> Ilya Yaroshenko: "I can't use druntime's cpuid so I defined my own." [...]
> IY: "..."
>
> It's this kind of stuff I need to have a better understanding of. Some technical arguments are meaningful, some others point to problems with obvious solutions that are somehow shunned, and yet others are like a hidden Markov model - I see the effects, but I don't see the causes.
>
>
> Andrei


My last argument was:
----
Linking compatibility. Assume A has builded a betterC library AA using GDC version XXX and B has builded a betterC library BB using LDC version YYY.

Question: how mister C can use BB and AA together in his C-library if both this libraries depends on different DRuntimes (compiler and version)?
----

DRuntime is large and evaluates fast. We have not backward binary compatibility in DRuntime and we have not binary compatibility between different compiler versions.

mir-glas is a betterC library for all languages.  It depends in mir-cpuid. I want mir-glas to replace OpenBLAS. To do it I need the same portability.

OK, assume we already have DRuntime for all targets including MIPS, POWER, armv7, aarch64, Loongson.

Does this solves problem? No.

The reason is very simple. All non-betterC D libraries must be compiled in lockstep: with the same compiler vendor and druntime version!

This will just kill GLAS. How this can be packed for Ubuntu for example? It will depends on LDC libphobos == XXX. Another numeric library, say FFT, will depend on libphobos == YYY by GDC. How they can be linked if they require different DRuntime from different compilers? Or different druntime versions for the same compiler?

Do you want to constraint D users to do not distribute binary libraries in popular repositories like Debian/Ubuntu?

DRuntime incompatibility is a huge constraints for business. Do you want to force all companies to use identical version of compiler and identical vendor?

Yes, C++ changes their API, but it few orders of magnitude slower then D. And they support multiple branches with bugs fixes. D supports only the recent one.

This is why GLAS/cpuid need to be a betterC library.

Ilya

On 12/18/2016 03:10 PM, Ilya Yaroshenko wrote:
> On Sunday, 18 December 2016 at 19:28:24 UTC, Andrei Alexandrescu wrote:
>> On 12/18/2016 01:49 PM, Ilya Yaroshenko wrote:
>>> On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright wrote:
>>>> On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote:
>>>>> We already have better `cpuid` and better `random` packages.
>>>>
>>>> Great! Please PR them for Phobos.
>>>
>>> cpuid is used in Mir GLAS and it should be a betterC library.
>>
>> It's this kind of imaginary dialog that I don't quite grok:
>>
>> Ilya Yaroshenko: "I can't use druntime's cpuid so I defined my own."
>> [...]
>> IY: "..."
>>
>> It's this kind of stuff I need to have a better understanding of. Some
>> technical arguments are meaningful, some others point to problems with
>> obvious solutions that are somehow shunned, and yet others are like a
>> hidden Markov model - I see the effects, but I don't see the causes.
>>
>>
>> Andrei
>
>
> My last argument was:
> ----
> Linking compatibility. Assume A has builded a betterC library AA using
> GDC version XXX and B has builded a betterC library BB using LDC version
> YYY.
>
> Question: how mister C can use BB and AA together in his C-library if
> both this libraries depends on different DRuntimes (compiler and version)?
> ----

My understanding is that if cpuid_v2.d does not pull any dependency, it doesn't matter whether it sits in druntime or elsewhere. Is that the case?

> DRuntime is large and evaluates fast.

So is it moving too slow or too fast?

> We have not backward binary
> compatibility in DRuntime and we have not binary compatibility between
> different compiler versions.

Even if we don't, we can guarantee that core.cpuid_v2 adds no link-time dependency. We may offer it as a pure template library, or as C APIs. Whatever floats your boat. Is this enough for ensuring compatibility?



Andrei

On Sunday, 18 December 2016 at 20:16:11 UTC, Andrei Alexandrescu wrote:
> On 12/18/2016 03:10 PM, Ilya Yaroshenko wrote:
>> On Sunday, 18 December 2016 at 19:28:24 UTC, Andrei Alexandrescu wrote:
>>> On 12/18/2016 01:49 PM, Ilya Yaroshenko wrote:
>>>> On Sunday, 18 December 2016 at 17:41:31 UTC, Walter Bright wrote:
>>>>> On 12/18/2016 1:26 AM, Ilya Yaroshenko wrote:
>>>>>> We already have better `cpuid` and better `random` packages.
>>>>>
>>>>> Great! Please PR them for Phobos.
>>>>
>>>> cpuid is used in Mir GLAS and it should be a betterC library.
>>>
>>> It's this kind of imaginary dialog that I don't quite grok:
>>>
>>> Ilya Yaroshenko: "I can't use druntime's cpuid so I defined my own."
>>> [...]
>>> IY: "..."
>>>
>>> It's this kind of stuff I need to have a better understanding of. Some
>>> technical arguments are meaningful, some others point to problems with
>>> obvious solutions that are somehow shunned, and yet others are like a
>>> hidden Markov model - I see the effects, but I don't see the causes.
>>>
>>>
>>> Andrei
>>
>>
>> My last argument was:
>> ----
>> Linking compatibility. Assume A has builded a betterC library AA using
>> GDC version XXX and B has builded a betterC library BB using LDC version
>> YYY.
>>
>> Question: how mister C can use BB and AA together in his C-library if
>> both this libraries depends on different DRuntimes (compiler and version)?
>> ----
>
> My understanding is that if cpuid_v2.d does not pull any dependency, it doesn't matter whether it sits in druntime or elsewhere. Is that the case?
>
>> DRuntime is large and evaluates fast.
>
> So is it moving too slow or too fast?

It is too slow as library to contribute to and too fast as standard library to depend on.

>> We have not backward binary
>> compatibility in DRuntime and we have not binary compatibility between
>> different compiler versions.
>
> Even if we don't, we can guarantee that core.cpuid_v2 adds no link-time dependency. We may offer it as a pure template library, or as C APIs. Whatever floats your boat. Is this enough for ensuring compatibility?

I need to understand how it is can be done because I did not find a valid solution.

mir-cpuid has global symbols, they are accessed using extern(C) API. If multiple libraries trying to initialize it than it will be initialized only once.

extern C API does not solve a problem with DRuntime because current DRuntime is not a betterC library and it is huge. A huge betterC library is a problem too because it is less portable.

Anyway, if you find a proper solution please share it. How it can be implemented as template library? Does different libraries will have their own cpuid instantiations and __gshared symbols?

How modularity can break existing Phobos? Why not to allow new packages like mir-cpuid and std.allocator to be a betterC library with their own repository? This will not break existing Phobos and Druntime but this will allow me to write server and numeric software without copy-pasting Phobos codes. I prefer to fork something rather then copypast.

My plans to work on:
1. Low-level numeric libraries
2. Low-level fast async I/O adaptive generic event loop, asymmetric green threads, http2
3. Microelectromechanical systems

They will require new threads, new timers, new mutexes, new event loop (existing C libs are slow), to be used.

Existing one does not satisfy my requirements.

I do not earn any money for this work.

I am working on this projects because I believe in D and believe that my current and future clients will believe in D much more then now. I know what they need.

Ilya

On Sunday, 18 December 2016 at 18:49:33 UTC, Ilya Yaroshenko wrote:
> 1. Modularity: D should provide a very slim library (like std.traits and may be default GC with old core, which can be turned off or replaced). Other parts or Phobos/Druntime should be split into parts and the parts should have their own repositories. They should be dub packages with D Foundation review / control.

This would be awesome to have!!

tl:dr: Phobos is very bloated. Let's do something about it!

I absolutely agree that there's a lot of stuff that doesn't belong into Phobos.
Also many parts are outdated or have ugly APIs, but they can only be replaced if a superior community solution has evolved.
So why not "dubify" the optional parts of Phobos?

Solved Problem: Versioning
--------------------------

This also solves the versioning problem Andrei discussed last month nicely. For example when std.allocator was merged into Phobos a lot of builds broke because packages did can their dependency from dub to std.x.allocator, but many people were still compiling with an older compiler.

Solved Problem: High quality community libraries
------------------------------------------------

Moreover, at the last DConf there were many voices that D is lacking good community libraries (aka the gold libraries). So the Phobos collection could be one.

Btw one shouldn't forgot that people have already written a lot of replacements of Phobos modules and imho in most cases it made sense!

A quick list
------------

(this list is incomplete and intended as an example to show that for most parts of Phobos better solutions co-exists)

etc.c.sqlite (aka std.database)

-> https://github.com/buggins/ddbc
(and: https://wiki.dlang.org/Database_Libraries)

etc.c.zlib / std.zip

-> https://github.com/rcythr/archive

std.base64

-> https://code.dlang.org/packages/base-d

std.bigint

-> https://github.com/andersonpd/eris/blob/master/integer/extended.d

std.csv

-> https://github.com/eBay/tsv-utils-dlang

std.container

-> https://github.com/economicmodeling/containers (uses allocators!)

std.complex

I am pretty sure this is on Ilya's list as well ;-)

std.encoding:

-> https://github.com/e10s/d-base32

std.getopt

-> https://github.com/jasonwhite/darg
-> https://github.com/SirTony/commando
etc.

std.json:

-> https://github.com/s-ludwig/std_data_json

std.math:

-> https://code.dlang.org/packages/ctstdmath
-> https://github.com/libmir/mir-math

std.net.curl:

-> https://github.com/ikod/dlang-requests

std.net.isemail:

-> https://github.com/anton-dutov/mail
-> http://vibed.org/api/vibe.mail.smtp/Mail

std.signals:

-> https://code.dlang.org/packages/phobosx
-> https://code.dlang.org/packages/observe

std.socket:

-> http://vibed.org/api/vibe.http.websockets/
-> http://vibed.org/api/vibe.core.net/TCPConnection

std.stdio:

-> https://github.com/jasonwhite/io
-> https://github.com/schveiguy/iopipe
-> https://github.com/rejectedsoftware/vibe.d/blob/master/stream/vibe/stream/stdio.d

std.uri:

-> https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/uri.d
-> http://vibed.org/api/vibe.inet.url/
-> https://github.com/adamdruppe/arsd/blob/master/http2.d

std.variant

-> https://github.com/s-ludwig/taggedalgebraic

std.xml

-> https://github.com/lodo1995/experimental.xml
-> https://github.com/jacob-carlborg/orange


Also a lot of proposed Phobos modules already exist in the community:

std.color

https://github.com/TurkeyMan/color

std.decimal

https://github.com/andersonpd/eris/
https://github.com/jaypha/fixed

std.events (planned?)

-> https://github.com/etcimon/libasync


Of course many of these libraries are one man projects and aren't considered "high-quality", but the reason they exist in the first place shows that a lot of things just shouldn't be "standardized", but more provided with a "practical variant". We should focus solely on modules that can be standardized easily (std.traits, std.ranges, ...) or are required to create a unified experience (e.g. a common allocation/logging interface). Imho there's really no need to ship sth. like SQLite as part of the standard library.

Final remarks
-------------

- From a technical point of view there shouldn't be a problem to have a unified documentation experience etc.
- Thanks to Martin's awesome work, we already test a couple of "selected" DUB packages on every DMD/Druntime/Phobos commit

On Sunday, 18 December 2016 at 09:26:09 UTC, Ilya Yaroshenko wrote:

> Who is interested in betterC _modular_* standard library?

What exactly do you mean by "betterC"?  As far as I know, the `-betterC` switch just removes ModuleInfo generation.

Do you actually mean, a standard library that has fewer dependencies on druntime features?

Mike

On 12/18/16 7:31 PM, Seb wrote:
> tl:dr: Phobos is very bloated.

How does the D standard library compare in size with some other languages (C++, Rust, Go, Java, Python)?

> Let's do something about it!

I've said this several times, and it bears repeating. We want to make D entirely pay-as-you go, and offer full support to anyone working on it. The best "something" anyone can do about it is do good engineering work in the D mainline. That will automatically benefit all users of the D language, instead of balkanizing the community. Granted, the lure of the clean slate is strong, and more care is needed to mind backwards compatibility, but that's where the real impact is.


Andrei