Range Redesign: Copy Semantics

[Paul Backus]

On Wednesday, 24 January 2024 at 16:18:11 UTC, Steven 
Schveighoffer wrote:
> On Tuesday, 23 January 2024 at 18:21:47 UTC, Paul Backus wrote:
>> (If your response to this is "ok, we'll just have 
>> isForwardRange explicitly reject pointers", keep in mind that 
>> this problem also applies to generic wrapper types that use 
>> `alias this` or `opDispatch`. Are we really going to tell our 
>> users that it's their fault if their code breaks because they 
>> put a range pointer inside one of these types?)
>
> Wouldn't that be on the person who wrapped the type? I wouldn't 
> expect `RefCounted` to care that it's wrapping a range for 
> instance.

Yes, it would--which is exactly what I'd like to avoid. I don't 
want us to put ourselves in a position where we have to tell end 
users "you're holding it wrong" if they try to combine two 
generic library features like this.

In general, we should not make assumptions in our library code 
unless we are capable of enforcing them. Since we are, 
unfortunately, not capable of enforcing the assumption that all 
copyable ranges have forward-range semantics, we should not allow 
ourselves make it.

(Perhaps there's an opportunity for a language feature here? A 
`unique(T)` qualifier would help with this, for example.)

> Indeed, since copying is defined by default, it's more onorous 
> to properly create an input range. But so what? Can I tell you 
> how many times people copy an input range without realizing the 
> consequences today? At least if it's *explicit* that input 
> ranges should not be copyable, then you will be more aware of 
> the issue as the compiler complains about it.

I agree that permitting input ranges to be copyable puts more of 
a burden on the authors of range algorithms. However, given that 
there are edge cases where the burden of preventing copies *must* 
fall on someone other than the range's author, I would rather 
that person be the author of the generic algorithm than the end 
user.

My hope is that in practice, if Phobos itself contains some 
prominent examples of non-copyable ranges, these bugs will be 
found quickly during testing. That's obviously not as good as a 
reliable compile-time error, but it's not nothing.

> I don't know how bad it would be to deal with, it's not 
> something I have put a lot of consideration into, but I had 
> thought that this mechanism of preventing copying for things 
> that shouldn't be used from multiple copies sounds like the 
> proper way to prevent problems by default.

For what it's worth, I agree that in practice, most input ranges 
should be non-copyable. [That `readf` bug][1] we discussed a 
little while ago would never have existed if `LockingTextReader` 
had been non-copyable from the start, for example.

[1]: https://github.com/dlang/phobos/pull/8826