Range Redesign: Empty Ranges

[Paul Backus]

On Wednesday, 6 March 2024 at 16:47:02 UTC, Steven Schveighoffer 
wrote:
> On Wednesday, 6 March 2024 at 14:18:50 UTC, Paul Backus wrote:
>> On Monday, 4 March 2024 at 21:29:40 UTC, Jonathan M Davis 
>> wrote:
>>> 2. The range API provides no way (other than fully iterating 
>>> through a range) to get an empty range of the same type from 
>>> a range unless the range is a random-access range.
>>
>> Genuine question: what are the use-cases for this?
>>
>> In general, the capabilities of ranges are designed to serve 
>> the needs of algorithms. Input ranges exist because 
>> single-pass iteration is all that's needed to implement 
>> algorithms like map, filter, and reduce. Random-access ranges 
>> exist because they're needed for sorting algorithms. And so on.
>>
>> I'm not aware of any algorithm, or class of algorithm, that 
>> needs this specific capability you're describing. If such 
>> algorithms exist, we should be using them to guide our design 
>> here. If they don't...then maybe this isn't really a problem 
>> at all.
>
> When you need to pass a specific range type, and you want to 
> pass in an empty range of that type, how do you do it?

By "specific range type", do you mean a specific category of 
range (input, forward, random-access, etc.), or a specific 
concrete type?

If the former, this is already easy to do with existing language 
and library features (for example, in many cases you can use an 
empty slice).

If the latter, then the question I'm asking is, why do you need 
to do that?

Personally, I can think of plenty of times that I've needed to do 
the first thing, but I can't think of a single time that I've 
needed to do the second thing.

> The only tricky aspect is ranges that are references 
> (classes/pointers). Neither of those to me should be supported 
> IMO, you can always wrap such a thing in a range harness.

The main thing you lose by dropping support for reference-type 
ranges is interfaces. In particular, the interface inheritance 
hierarchy in `std.range.interfaces`, where `ForwardRange` 
inherits from `InputRange` and so on, cannot really be replicated 
using `structs` (`alias this` only goes so far).