Article: Why Const Sucks

[jmh530]

On Tuesday, 6 March 2018 at 15:39:41 UTC, Jonathan M Davis wrote:
> [snip]
>
> How well Phobos has done with this has improved over time as 
> more and better testing has been added (testing for reference 
> type ranges is probably the most critical to finding this 
> particular problem), but I doubt that Phobos has it right 
> everywhere, and I'm sure that the average programmer's code has 
> tons of these problems. Code mostly just works because most 
> code really isn't used with arbitrary ranges, and a large 
> percentage of ranges implicitly save on copy. It's not that 
> hard to get a piece of code working with a particular range or 
> just a few similar range types. It's when it needs to work with 
> _any_ range type that matches the template constraint that 
> things start getting hairy, and without thorough testing, it 
> simply doesn't happen unless the code is very simple and the 
> programmer in question is very mindful of stuff like save 
> (which most programmers aren't). And of course, since most 
> testing is done with dynamic arrays, issues with other range 
> types simply aren't found unless the programmer is really 
> putting in the effort to do their due diligence.

Someone could make a range testing library of sorts. Really just 
a variant packed with a bunch of different range types covering a 
variety of use cases. The user could import it in a 
version(unittest) block and then just loop through it and assert 
that the function works for all of them (would need some kind of 
variant full of what to compare it to for each type).

>
> Ranges are wonderfully powerful, but they become a royal pain 
> to get right with truly generic code. And that's without 
> getting into all of the arguments about whether stuff like 
> whether transitive fronts should be allowed...
>
> Ranges are definitely one area where we could really use some 
> redesign to iron out some of the issues that we've found over 
> time, but their success makes them almost impossible to fix, 
> because changing them would break tons of code. But annoyingly, 
> that's often what happens when you implement a new idea. You 
> simply don't have enough knowledge about it ahead of time to 
> avoid mistakes; those are easy enough to make when you really 
> know what you're doing, let alone with something new.
>
> - Jonathan M Davis

There's probably value in writing up a retrospective of sorts on 
D's ranges. What works about the design, what are the 
limitations, and what could be improved (depending on the level 
of breakage considered acceptable). Even if D takes a long time 
to fix these issues, making the information more easily available 
to others outside the D community might be valuable.