A betterC modular standard library?

[Seb via Digitalmars-d]

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