Isn't `each` too much of a good thing?

H. S. Teoh hsteoh at
Thu Sep 17 18:28:05 UTC 2020

On Thu, Sep 17, 2020 at 05:41:56PM +0000, Seb via Digitalmars-d wrote:
> On Thursday, 17 September 2020 at 16:18:18 UTC, Andrei Alexandrescu wrote:
> > But this kind of stuff has no place in stdv2021.
> The only way for this to ever happen is if we start with it. One
> function at a time.

Indeed.  We've been talking about std.v${next} for what, almost (or
already?) a year now?  Time to take action.

> I suggest simply creating a new repository and starting from zero.

Yes, yes, yes!

> Apart from the clear mental divide and separation, this has the added
> advantage that we can just keep druntime and phobos as is and work on
> a new combined "base" library. There are a few others like being able
> to immediately ship it via dub or being able to use GitHub's features
> (issues, projects, roadmaps, ...).

This is a good way to start from a clean slate.  Say we set it up such
that you could use a compiler switch to switch between current-Phobos
and new-Phobos.  Maybe with a path override or some such.  Make it easy
to test the new library with existing code, but without the forced
commitment and breakage of actually replacing current-Phobos.  This
would allow us to test the state of the new library against existing
code and gauge how well we're doing / determine what kinds of breakages
might occur and what migration path(s) are available for people who want
to upgrade their code.

Also, we should use a disjoint namespace so that when new-Phobos does
become official, old code can still continue working as-is (maybe add a
path or two so that the compiler can find legacy-Phobos).  I propose
std.v2.* -- with the anticipation that, a decade or so from now, there
will be a std.v3.* which can be added without breaking all prior code.
As Andrei has said -- stop changing, start adding.


We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL

More information about the Digitalmars-d mailing list