On Friday, 2 June 2017 at 21:59:42 UTC, Jonathan M Davis wrote:
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.
Mir random access ranges (ndslices) are input ranges. The
performance benefit comes from the way how they are implemented,
constructed, and iterated.
Also, ndslice can be created in top of a range that have only one
primitive opIndex. A user can define his own ndslices with all
possible range primitives very fast - define a struct with
opIndex method and use sliceField to construct ndslice on top of
it.
Ilya