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
