Range Redesign: Copy Semantics

[Richard (Rikki) Andrew Cattermole]

On 23/01/2024 4:41 AM, Atila Neves wrote:
> On Sunday, 21 January 2024 at 05:00:31 UTC, Jonathan M Davis wrote:
>> I've been thinking about this for a while now, but with the next 
>> version of Phobos which is in the early planning stages, we really 
>> should do some redesigning of ranges. Most of their API is just fine 
>> how it is, but there are some aspects of it which really should be 
>> changed if we want them to be better (the most obvious one being the 
>> removal of auto-decoding). But what I'd like to discuss specifically 
>> in this thread is fixing - and defining - the semantics of copying and 
>> assigning to ranges. Specifically, the semantics of stuff like
>>
>> [...]
> 
> I don't think I've ever encountered a situation where reference ranges 
> would have been desirable - I've never used one.
> 
> I think that `.save` was a historical mistake, and that ranges that can 
> be copied are forward ranges. Something like a range reading from stdin 
> or a socket would/should disable the copy/postblit constructors.
> 
> Has anyone here used the class-based ranges?

I did experiment with them when I first learned ranges.

Nothing is set up for them.

But they do two things extremely well:

1. Create confusion, they are not the definition of what a range is, nor 
are they used anywhere.
2. Of course since then I've also learned that they offer opportunity to 
prevent optimizations, so not a great solution to be tied to.

I want signatures. I've told Adam Wilson that if you want me involved 
with ranges for PhobosV3 at the very least I want the compile time 
aspect. The current situation with ranges not being properly documented 
in API is just not good enough.

Signatures do have a runtime aspect, they can represent ranges if you 
need a reference, we can also implement something like save via that 
(even if the implementation doesn't have it).