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.

Reply via email to