Transitioning std lib modules/packages

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Mon Nov 28 08:00:00 PST 2016


On Monday, November 28, 2016 09:59:28 Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 11/28/16 9:09 AM, Ilya Yaroshenko wrote:
> > Compiler version should be split from a library versions. --Ilya
>
> On 11/28/16 9:26 AM, Ilya Yaroshenko wrote:
> > I propose Phobos to be an a packed by default collection of libraries
> > with clear dependencies and community support. A package version should
> > be overridable in dub configuration. This is what we need to involve
> > companies to invest their efforts in dlang infrastructure. --Ilya
>
> This is interesting stuff but I don't know of any precedent, so we'd be
> taking risks trying this. All language platforms I know of ship with one
> compiler tied to one fixed standard library implementation. (Then, third
> party libraries come on top of that.) The obvious issue with not doing
> that is dealing with maintaining a fuzzy combinatorial number of setups
> instead of one. The risks may, of course, be justified if this turns out
> to be a nice innovation but definitely the tradeoffs must be analyzed
> properly.

I confess that I fail to see the benefit. It's normal for the compiler and
standard library to be tied together. This sounds like an attempt to get rid
of the standard library entirely in favor of _everything_ being 3rd party
code, which seems like the complete opposite direction that the programming
community at large has been going. We should obviously support 3rd party
software, but why would turning the standard library into 3rd party software
make sense?

If someone wants to create an alternative implementation to something in the
standard library, that's perfectly normal. Maybe they have a use case that
would be better served by a more specialized API or implementation. There's
no need to get the standard library involved with that, and if you can't
rely on knowing that std.algorithm or std.datetime or std.random or
std.whatever is the one from the actual standard library when you read the
code, that seems like a recipe for disaster. It's not standard anymore at
all.

I say leave 3rd party code in 3rd party land, and standard stuff should be
left in druntime/Phobos. And if someone wants to go through the review
process and get 3rd party stuff into Phobos and make it standard, then
great. But dub already makes it possible for folks to create their own
libraries and distribute them to others to use in their projects if they
don't want to go through the process of trying to get them included in
Phobos or don't think that they belong in the standard library. Phobos and
its review process doesn't need to be involved with whatever folks want to
do with 3rd party libraries on dub, and I don't see any reason to try and
treat the standard library - or any part of the standard library - like a
third party component.

- Jonathan M Davis



More information about the Digitalmars-d mailing list