Range Redesign: Copy Semantics

Jonathan M Davis newsgroup.d at jmdavisprog.com
Mon Jan 22 02:08:34 UTC 2024


On Sunday, January 21, 2024 10:39:41 AM MST Richard (Rikki) Andrew Cattermole 
via Digitalmars-d wrote:
> On 21/01/2024 11:58 PM, Jonathan M Davis wrote:
> > 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).
> Umm, why would we bring back Nullable?
>
> By then we'd have sum types which can represent it in the language far
> better.

Much as I know that you like the idea of sum types, AFAIK, it's never been
officially agreed that we're going to have them in the language, and even if
we do get them, I don't know what that's actually going to look like. If
it's anything like std.sumtype, IMHO, it would be utterly terrible for when
you want a Nullable type. For that, you want to be able to ask whether the
object has a value, and if it does, you want to be able to fetch its value.
So, while you could use different function names for it, you basically want
the same kind of API that a pointer has. Something where you'd have to pass
delegates in just to get the value out would be incredibly annoying and
bloated in comparison (and personally, I hate std.sumtype in general because
of that design, but it makes a lot more sense when you have a variety of
possible types as opposed to just one which may or may not be there).

But regardless of whether sum types would make sense in this case (which I
very much question), we'd have to know that they were definitely being added
to the language and what exactly that would look like - and they would have
to function in a way that was clearly superior to have a dedicated Nullable
type, or it would make more sense to add a Nullable type and use that for
cases where you want a nullable object.

Obviously, if sum types get added to the language soon enough, and they
really do replace the need for Nullable, then Nullable probably won't be in
Phobos v3, but as thing stand, I would fully expect it to be there. Either
way, using the API of a pointer makes a lot of sense for the proposed basic
input range API, in which case, a range that wanted to return something
other than a pointer would need to return a type that used the same API.

- Jonathan M Davis





More information about the Digitalmars-d mailing list