Vision for the first semester of 2016

Ola Fosheim Grøstad via Digitalmars-d-announce digitalmars-d-announce at puremagic.com
Thu Jan 28 01:16:50 PST 2016


On Wednesday, 27 January 2016 at 21:00:41 UTC, Martin Nowak wrote:
> 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.

I don't think this is the right criteria. Take a good hard look 
at the C++ standard library.
Plenty of things in there that nobody use, but which one would 
hope that almost everyone would use. Like for numerics.

When a good external numerics library emerge it will displace 
whatever numerics functionality the standard library provides.

D has too few users to see high quality external libraries, but 
that is not a good reason to bloat the standard library.

The argument that some functionality is needed on a daily basis 
is also misguided. Different applications have different needs.

What the standard library should support is essential interfacing 
with the system and what you need to interface with libraries, 
like basic types/iterators.

Once you have something in the standard library you have to 
maintain it forever. If something is in the standard library and 
it turns out to be impossible to implement it efficiently on a 
specific hardware platform then all libraries using that 
functionality will be dog slow on that platform.

> 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 is no reason for xml or json to be in the standard library. 
You can have a set of recommended libraries, allowing for more 
efficient APIs to emerge over time.

Only functionality where you get unbreakable interdependencies 
between standard modules need to be in standard library.

Parsers and compressors have low levels of inter-library 
dependencies. DSP functionality has only internal dependencies. 
No need for such things in the standard library.


Scripting languages like Python is a horrible example to follow. 
Scripting languages require all C-implemented functionality to be 
in the standard library for the sake of being able to deploy pure 
python code on machines where you don't get to install binaries.



More information about the Digitalmars-d-announce mailing list