std.v2020.algorithm etc[ WAS: Is run.d going to be expand for runtime and the phobos library?]

[Jon Degenhardt]

On Tuesday, 23 June 2020 at 05:19:35 UTC, Andrei Alexandrescu 
wrote:
> On 6/22/20 6:54 PM, Jon Degenhardt wrote:
>> On Monday, 22 June 2020 at 02:52:57 UTC, Andrei Alexandrescu 
>> wrote:
>>> On 6/21/20 10:47 AM, Andrei Alexandrescu wrote:
>>> One more thing before I forget - we should drop classes that 
>>> are ranges. They add too much complication. The functionality 
>>> would still be present by wrapping a polymorphic 
>>> implementation in a struct.
>> 
>> I have used class-based ranges quite a bit to implement ranges 
>> with reference semantics. Classes are very convenient for this 
>> because the implementation is structurally very similar to a 
>> struct based implementation. Typically, replace 'struct' with 
>> 'final class' and modify a helper function constructing the 
>> range to use 'new'. It's amazingly easy.
>
> Problem is they're cumbersome to use - you need to remember to 
> call save() in key places, and if you forget the compiler will 
> be mum about it. If we do away with class ranges, save() can be 
> eliminated in favor of the copy ctor.
>
> I assume a wrapper that does define reference semantics where 
> needed would not be difficult to write.

A couple thoughts. First, my uses for reference ranges have so 
far been on non-forward input ranges, so no 'save' function. No 
built-in member for copying either. I'm now wondering if there is 
some structural correlation between these choices and my 
application use cases, or if it is purely accidental.

Second - If I'm designing a range intended to have reference 
semantics, I'd expect it to be easier to build that choice into 
the main implementation of the range. If the implementation needs 
to be in two parts, a value-based, copyable range, and a separate 
wrapper to define reference semantics, then I'd expect it to be 
more complicated. Even if the wrapper is found in the standard 
library.

Simple things like decisions on how to organize unit tests. Are 
there two sets of unit tests, one for the value-based layer, and 
a second for wrapped layer? (I.e. If the value based layer can 
never be directly instantiated, should it have standalone unit 
tests?). And slightly harder things, like can the value based 
implementation layer assume it is never instantiated as a 
standalone value-based range? It sounds like more design 
decisions to achieve the goal.