On Tuesday, 26 January 2016 at 12:38:09 UTC, Andrei Alexandrescu
wrote:
including things that some people argue shouldn't be part of a
standard library: archives and compression, cryptography,
databases, character encodings (including json and xml!), html
templating, image processing, suffix arrays (sic), logging,
networking, regexp, testing, tokenization.
See my answer below, most of these are standard solutions that
you need on a daily basis (except for the suffix array).
I do agree with Dub's importance. What's unclear to me is what
are reasonable criteria for including some given functionality
within the stdlib vs. an external one.
A good criteria is whether some area has an established and hard
to debate solution, then it can go into the standard library. But
if there are many different ways around the same topic you should
leave the decision to the users.
So for example there are 3 established ways to parse something,
dom, stax and event based parsers. So you can add those parsers
as sth. like std.xml or std.json.
There are about 500 different configuration file formats, so
anything that isn't as established as xml or json should be left
for libraries.
Likewise there are plenty of different GUI toolkits (taking
imperative or declarative approaches). Leave it to people to pick
one that suites their need.
You could discuss endlessly about the syntax of html templating,
but how such a library should work is clear. This is at the edge
of standardizable, b/c by putting it into std, you're making a
decision for all language users. It's albeit possible, just like
declaring a particular code style as standard.
Anything that is highly innovative or experimental should never
go into standard libraries.
