Range Redesign: Copy Semantics

[Jonathan M Davis]

On Sunday, January 21, 2024 3:36:37 AM MST Per Nordlöw via Digitalmars-d 
wrote:
> On Sunday, 21 January 2024 at 05:00:31 UTC, Jonathan M Davis
>
> wrote:
> > I've been thinking about this for a while now, but with the ...
>
> Shall
>
> - `Nullable.opCast` to `bool`
> - `Nullable.opUnary` `*`
>
> be added to Phobos' `std.typecons`?

Maybe. It probably should be, though I don't know how many changes like that
we're going to do to the current version of Phobos.

Either way, if we're doing a new major version of Phobos, we'll be reworking
a variety of stuff anyway, and so Nullable would presumably be on the list
(e.g. I think that it was a big mistake to make it a range, and I'd remove
that functionality; slicing it to get a range is one thing, but the fact
that it itself is a range definitely causes problems in generic code). And
if the new API for basic input ranges uses a pointer API to access its
elements, then that's a very good reason to make Nullable support that. As I
said in my post, I suspect that the main reason that the current version
doesn't is because it originally used alias this - which we removed due to
all of the bugs that that caused, but giving Nullable an opCast to bool and
* for dereferencing would likely have been a terrible idea when Nullable
used alias this, whereas without that, I can't think of any reason why it
would be a bad idea - though I'd likely still choose to have get and isNull
for those who wanted to make it clear that a Nullable was being used. But I
think that it's better to use a pointer API for basic input ranges, because
then they can actually use pointers in those cases where that makes sense
instead of requiring a Nullable type, much as it also needs to work to use a
Nullable type.

- Jonathan M Davis