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

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Jun 23 05:19:35 UTC 2020


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.
> 
> So - What aspects of class-based ranges is it valuable to drop? 
> Polymorphism/inheritance? Reference semantics? Both?
> 
> I haven't found a need for polymorphism in these ranges, just reference 
> semantics. I realize that the Phobos experience is the opposite, that 
> reference ranges are rarely used. Could be that my design choices could 
> be modified to eliminate reference ranges. Could also be that approaches 
> needed in general libraries are not always necessary in code targeting 
> specific applications. Not trying to make hard claims about this. Just 
> pointing out where I've found value.

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.



More information about the Digitalmars-d mailing list