Phobos 2

Fri Jun 2 14:59:42 PDT 2017

On Friday, June 02, 2017 13:37:05 H. S. Teoh via Digitalmars-d wrote:
> On Fri, Jun 02, 2017 at 02:43:32PM -0400, Andrei Alexandrescu via
> Digitalmars-d wrote: [...]
>
> > 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.
>
> Haha, I happened to be reading Spolsky's blog, and came across this:
>
>   https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part
> -i/
>
> Especially the bit about throwing away years of accumulated programming
> work.

I don't entirely agree with his sentiments on that one, but he does have a
point. Throwing the baby out with the bath water is obviously something to
avoid, but sometimes redoing code from scratch does really fix problems -
especially when the original has serious design problems that can't be fixed
without redoing it. However, thinking about what he's saying there, it
starts looking like the most valuable part of your code base is your tests
(assuming that they're thorough), because then if you do completely rewrite
something, you can verify that it's correct.

As for "Phobos 2" specifically though, I have very mixed feelings about such
an idea. Being able to rearrange things how we'd like and fix some of the
mistakes that we've been stuck with would be great, but you're basically
planning on breaking every single D program, even if it's not immediately
and folks could switch over to std2 (or whatever the package was) at a point
that made sense for them. And especially if you're talking about
range-related stuff, you'd be essentially splitting the D community and its
code in two, because you'd almost certainly be dealing with incompatible
libraries - especially if you're actually fixing some of the range-related
problems. And that sort of thing just seems like it would be too destructive
to be worth the risk. It's not quite a language split like you got with
something like python 2 and python 3 or D1 and D2, but if the old and new
standard libraries were not compatible, it would be close to that - it also
seems too much like the whole Phobos vs Tango mess, even if the idea would
be to be transitioning from one to the other rather than really having
competing libraries (but as we've seen with python 2 vs 3 and D1 vs D2,
major transitions like this tend to result in the old and the new competing
even if that's not the intent).

And honestly, for the most part, I don't think that redesigning the standard
library would actually buy us much. Aside from range-related issues,
everything I can think of is essentially a minor annoyance or wort. Sure, it
would be nice if we could fix it, but it's not worth a massive upheaval of
the D ecosystem. The only stuff that I can think of right now that would be
a huge gain if we could change it is range-related stuff. I can think of
several items there that would be nice to fix or at least look at changing:

1. Get rid of auto-decoding ranges and the concept of narrow strings. string
and wstring would be ranges of char and wchar, everything operating on
characters would then be operating at the code unit, code point, or grapheme
level (depending on what was appropriate for the algorithm), and generic
stuff would just operate on the elements regardless of whether they were
code units, code points, or graphemes, leaving it to the programmer to
handle it correctly.

2. Get rid of save and disallow classes as ranges. Postblit constructors
then do what save does now. If you want a class to be a range, then wrap it
in a struct, kind of like a smart pointer but for ranges.

3. Examine how to better deal with input ranges vs forward ranges and look
at requiring that input ranges have reference semantics whereas forward
ranges must have value semantics (as it stands, an input range _without_
reference semantics really should be a forward range, but forward ranges can
still have reference semantics - hence the need for save).

4. Investigate adjusting the range hierarchy so that we have random-access
ranges which aren't input ranges. I don't know for sure that that makes
sense, but as I understand it, Mir does something like that, because it has
a definite performance benefit under some circumstances.

5. Look at whether a car/cdr approach would be better for input ranges (and
maybe any range that isn't random-access) than front/popFront. Andrei wants
to do something with that for immutable ranges, and it could help resolve
the issue of const ranges if that's what we did in general (but without
something like Phobos 2, I personally think that such a change is too
drastic even if Andrei is currently thinking about it for immutable
containers).

6. Look at improving output ranges so that you actually know whether
something is going to fit in them - possibly by having a type of output
range that has a length or some other member indicating the space remaining.

7. Look at formalizing what std.digest did with output ranges and have a way
to indicate that you're done putting stuff in them so that they can do
something and "close" or "complete" the range.

And there are probably more things that we could look at with ranges, which
would be nice to fix. So, being able to go back to the drawing board on some
level with ranges would be _fantastic_, but to do so would break most
everything, and aside from ranges, I really don't see much gain in a "Phobos
2". Aside from nitpicks with names and whatnot, it should be possible to
make most changes without doing a full, new iteration of the standard
library.

And as Daniel Murphy pointed out several times at dconf, if you really step
back and just use D as it is, it's pretty darn fantastic, and there's too
much going with folks trying to make it perfect. Yes, D and Phobos have
warts. Yes, it would be nice to make some improvements which would not be
backwards compatible. But what we have is already pretty amazing, and when
fixing something requires pulling the rug out from _everyone_ using D, you
have to really consider that it's better having something amazing but
imperfect than to try and fix it. Yes, sometimes, drastic changes are worth
the breakage - especially when most of the required changes actually results
in bugs being fixed - but redoing the standard library? That really seems
like too big a change.

- Jonathan M Davis