Phobos 2

[9il via Digitalmars-d]

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