Range Redesign: Copy Semantics

[Alexandru Ermicioi]

On Wednesday, 24 January 2024 at 20:08:56 UTC, Jonathan M Davis 
wrote:

> Traits like that can test (and thus be used to enforce) _some_ 
> of the semantics, but there are plenty of things that can't be 
> tested statically (like what popFront actually does). They are 
> able to test that certain code will compile with the range API 
> (or that certain code won't compile) using the type that 
> they're instantiated with, and they can test certain explicit 
> stuff about the type (e.g. enforcing that it's a struct if we 
> want to do that), but they can't actually test what the 
> functions do.
>
> So, while we can enforce that a forward range is copyable, we 
> can't enforce what its copy semantics are beyond disallowing 
> stuff like classes or pointers to structs, since those are 
> clearly reference types. But the struct itself could have a 
> variety of copy semantics depending on its implementation, and 
> there's no way to determine that statically. Ultimately, for a 
> range to have the correct copy semantics, we have to rely on 
> the programmer to implement them correctly, just like we have 
> to rely on them implementing what front, popFront, and empty do 
> correctly.

That's what unit tests are for, while those traits act like 
pseudo interfaces. Maybe there could be a test suite provided in 
Phobos for user to run over his own range implementations, in his 
own unit tests. This would make easy to spot whether user's range 
does or does not follow proper logic.