std.experiemental

Jonathan M Davis newsgroup.d at jmdavisprog.com
Wed May 15 12:06:50 UTC 2019


On Tuesday, May 14, 2019 6:21:57 AM MDT Alex via Digitalmars-d wrote:
> Seems to be an issue about changing it.
>
> Why not just change the name
>
> std.experimental->std.experimental2
>
> and people that have code just need to do a mass module change
> ("import std.experimental" -> import std.experimental2;")
>
> This then does break backwards compatibility but is a simple
> bridge to solve the problem.
>
> By having some type of versioning one could report when someone
> uses a new module that will break old code.
>
> Could use dates
>
> module std.experimental_04_05_2019;
>
> Then one simply has to import it by date. This separates all
> experimental and allows backwards compatibility and solves future
> issues.

Completely aside from the versioning issues brought up in this thread,
another point that Andrei had for why we want to use code.dlang.org instead
of std.experimental is that it gives the chance for us to take projects that
have proven themselves over time and merge all or part of them into Phobos
after they're thoroughly battle-tested. So, we're able to take APIs and
implementations that have proven themselves, whereas what has happened with
std.experimental (and much of what was merged into phobos prior to
std.experimental) thus far is that stuff gets designed explicitly for Phobos
rather than being battle-tested first. And the fact that something is in
std.experimental creates this weird situation where people _can_ use it, but
many don't, because it's experimental, and those who do get mad when it
changes, because their code breaks. So, we have problems updating what's in
std.experimental, and it's not necessarily getting battle-tested the way
that it should, because it's labeled as experimental. It really has not
worked well for us.

Using code.dlang.org as the proving ground for projects allows us to
function more like what happens with Boost and C++'s stdlib, which has been
very successful for them. Andrei seems to now strongly favor that approach.

There's also the issue that on some level, code.dlang.org negates the need
for putting stuff in phobos. Some stuff should end up in Phobos at some
point, but unless it's something that really needs to be standard, there
isn't necessarily a good reason to. Having it available via the official
package manager means that it will be available without needing to actually
get it into Phobos.

- Jonathan M Davis





More information about the Digitalmars-d mailing list