Range Redesign: Empty Ranges

[Meta]

On Wednesday, 6 March 2024 at 21:17:37 UTC, Jonathan M Davis 
wrote:
> On Wednesday, March 6, 2024 1:23:52 PM MST Meta via 
> Digitalmars-d wrote:
>> Couldn't we somehow fit RefRange into the
>> current range hierarchy somewhere, and provide primitives to 
>> make
>> it more difficult to shoot yourself in the foot?
>
> RefRange was a huge mistake (and it was my mistake). It's 
> basically trying to force reference semantics on something that 
> has value semantics, and it causes problems as a result. I 
> don't think that it can actually be made to work properly - at 
> least not with forward ranges.
>
> IMHO, we need to be able to rely on the semantics of the basic 
> range operations, and most of the problems with the current 
> range API come from when operations are under-specified or 
> outright unspecified - be it because we're trying to support 
> too much (e.g. both structs and classes for ranges), or because 
> we just didn't actually think to specify what the behavior 
> should be. And in some cases, we though of it but too late to 
> actually require it (e.g. you can't actually rely on $ working 
> with random-access ranges, because we didn't think to require 
> it up front, and too many random-access ranges had been written 
> that didn't support it by the time we realized our mistake).
>
> - Jonathan M Davis

I don't mean the type RefRange; I mean expanding the range 
hierarchy to include the concept of a "RefRange" (just like 
InputRange, BidirectionalRange, etc.) that explicitly has 
reference semantics instead of value semantics. Then you can 
specialize algorithms on whether they're a ref range or not 
(implying that ranges with reference semantics should no longer 
pass the isInputRange et al. checks - no idea how you'd do that 
OTOH), and then you can account for that fact in the 
implementation of the algorithm, rather than all range algorithms 
currently carrying an implicit assumption that they're working 
with a value range.