Range Redesign: Copy Semantics

[Jonathan M Davis]

On Wednesday, January 24, 2024 2:31:19 PM MST Alexandru Ermicioi via 
Digitalmars-d wrote:
> 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.

Of course that's what unit tests are for, but that doesn't enforce anything.
That's the programmers making sure that their code behaves the way that it
should - that their code follows the conventions required by the range API.
On the other hand, what Paul was talking about was actually statically
enforcing the semantics via template constraints rather than relying on
coventions, which is something that we can do with some portions of the
semantics of the range API but can't do for a good chunk of it.

> 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.

Well, we can provide test ranges to use to test a function with, but not
much can be automated there, since the results would depend on what the
function actually did. However, if there were set of standard range types to
test with, then it would at least be easier to test a proper range of range
types. Phobos itself doesn't always do a good job with that though.

As for testing that a range behaves properly, that might be possible to
automate, but since it's usually the case that a range comes from a
function, that's not always straightforward. And while how the range should
behave is largely defined by the range API, not all ranges are generic with
regards to what they work with (e.g. what their element type is) or how
they're constructed, so writing a generic set of tests could be challenging.
Off the top of my head, I don't know how possible it would be, though I'm
sure that it could be made to work with a subset of ranges.

All in all, providing better testing tools is a good idea, but a lot of the
question here is what we can statically enforce, since the more that we can
statically enforce, the harder it will be to write range-based code that
does the wrong thing, and the harder it will be to pass types to a
range-based function which then won't behave properly even if the function
is written properly.

- Jonathan M Davis