Phobos 2

[Jonathan M Davis via Digitalmars-d]

On Friday, June 02, 2017 14:43:32 Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 06/02/2017 01:43 PM, H. S. Teoh via Digitalmars-d wrote:
> > On Friday, 2 June 2017 at 09:14:14 UTC, qznc wrote:
> > [...]
> >
> >> D has a painful history with two competing standard libraries. If you
> >> seriously propose this path, I hope Andrei and Walter will publicly
> >> and vehemently oppose it. Otherwise that ghost from the past becomes a
> >> PR disaster for D.
> >
> > [...]
> >
> > I think this is overreacting.  "Phobos 2" is not supposed to be a
> > *competing* library, but, as I see it, more like an alpha version of the
> > next "major iteration" of Phobos. The "next major version" with a brand
> > new paradigm, if you will, as opposed to incremental changes to the
> > "current major version".
>
> A clean slate is alluring, and there are several things that can be done
> differently in Phobos, as there are in any project that's been around
> for a while. It may, however, be difficult to find enough people able
> and willing to take such a large project off the ground. There are
> plenty of great things that can be done with the standard library,
> ranging from the trivial - documentation, fixes of bugs triaged as
> "trivial" or "bootcamp" etc - to the most creative.
>
> As an example, eliminating phobos' and druntime's reliance on "static
> this" would improve conviviality of D in mixed-language projects, but we
> have yet to find folks to do the work. To the best of my knowledge only
> David, Stanislav, and myself have been involved so far.

A related point is what's happened with modules like std.json and std.xml.
We've said for years that they need to be replaced. But have they been? No.
Some work has been done with the idea that it would replace them, but either
it's never been done, or there was too much arguing over the replacement and
what it should do for it to get through the review process. We can't replace
these two modules, and we're now talking about the possibility of redoing
the entire standard library? When you think of it that way, it seems insane,
even if it might be desirable.

Sure, if we were going to redo Phobos, most of it would probably just be
transferred to "Phobos 2" but rearranged as appropriate rather than
completely redone, but stuff like revamping ranges would affect almost
everything in Phobos, making that a _major_ task even without considering
how it would affect all of the D code that isn't in Phobos but uses it. I
think that we've pretty much proven that we can't do that with the current
level of manpower.

And of course, doing stuff like adjusting Phobos to mitigate the effect of
auto-decoding or to revamp function signatures such that most overloads are
done internally with static ifs where possible - or the static constructor
issue - all are smaller things that we have trouble getting done even when
we mostly agree that they should be done. We do get some work done, to be
sure, but we need more eyes on pull requests so that they get merged in a
timely manner and more pull requests to fix these smaller issues. If we
can't even do those right, how could we possibly revamp all of the standard
library?

I can certainly empathize with the sentiment that it would be nice to go
back to the drawing board on some things, but I think that doing that with
the whole standard library is just too much - both from the standpoint of
manpower and with regards to how much code it would ultimately break.

- Jonathan M Davis