Range Redesign: Copy Semantics

[Paul Backus]

On Wednesday, 24 January 2024 at 12:26:43 UTC, Nick Treleaven 
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?)
>
> `isForwardRange` could require the range *type* to have `empty, 
> front, popFront` defined. Not sure if that solves your `alias 
> this`/`opDispatch` points. This would mean arrays would need 
> the range methods built-in rather than using UFCS.

It could, but I don't think it's a great idea, because it would 
make ranges a special case. Along with all of the usual reasons 
special cases are bad, ranges are one of the first things new D 
programmers are going to encounter, and are pretty much the 
canonical example of introspection and structural typing in D. If 
we make ranges behave differently, users who learn from them are 
going to have a much harder time understanding every *other* use 
of introspection.