Range Redesign: Copy Semantics

Jonathan M Davis newsgroup.d at jmdavisprog.com
Sun Jan 21 13:54:22 UTC 2024


On Sunday, January 21, 2024 6:26:16 AM MST Alexandru Ermicioi via Digitalmars-
d wrote:
> On Sunday, 21 January 2024 at 10:58:32 UTC, Jonathan M Davis
>
> wrote:
> > 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.
>
> Imho, it must not be added, as this might conflate with contents
> of `Nullable!bool` types.

It doesn't conflate with Nullable!bool at all, because the alias this was
removed from Nullable. The only way to get the value out of Nullable is to
use its get member. If we added dereferencing to it, then dereferencing it
would then also work to get its value, but if we added an opCast to bool,
casting would never give the Nullable's value even if the type of its value
were bool. It would just be equivalent to negating the result of isNull.

I agree that if we still had alias this on Nullable, then adding opCast to
bool to it would be problematic - and that's likely why it doesn't have that
opCast, since its original API included alias this, but since the alias this
is now gone, that's no longer a problem. There is no ambiguity.

- Jonathan M Davis






More information about the Digitalmars-d mailing list