Range Redesign: Copy Semantics

[Jonathan M Davis]

On Wednesday, January 24, 2024 11:20:38 AM MST Paul Backus via Digitalmars-d 
wrote:
> On Wednesday, 24 January 2024 at 17:35:32 UTC, Paul Backus wrote:
> > 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.
>
> Having thought about it some more, this is a bad argument, and I
> withdraw it.
>
> The entire range API is based on convention to begin with. Of
> course there's no enforcement mechanism!

Yeah. We can enforce some stuff statically (e.g. we can require that a
forward range be a dynamic array or a struct, since if it's a class or a
pointer, we know for sure that it doesn't have the right copy semantics),
but we can't actually enforce the correct copy semantics statically - just
like we can't enforce the correct copy semantics with save right now. We
can't even enforce that popFront removes an element from the range or that
empty has anything to do with how many elements the range has. We can
improve the situation with the API (e.g. getting rid of the requirement for
save), and we can try to make it easier to use correctly and harder to use
incorrectly, but unfortunately, there's no way to not rely on convention on
some basis.

- Jonathan M Davis