Vision for the first semester of 2016

[Martin Nowak via Digitalmars-d-announce]

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.