On Friday, 28 February 2025 at 01:06:01 UTC, Paul Backus wrote:

Yes, you can, but why? What are you gaining from using SumType there? It can hold only one value for God's sake...

I am probably missing something, so please enlighten me.

On Friday, 28 February 2025 at 11:33:50 UTC, Dejan Lekic wrote:

The short answer is: it deals with edge cases around initialization and destruction.

Current Nullable is basically doing the same thing (if you read the source, it stores its value in a union), but it's inventing it from scratch instead of re-using SumType. This is bad for maintenance: I have personally found, and fixed, bugs in Nullable, for which the equivalent bug in SumType had already been fixed multiple releases ago (PR 7581 and PR 7582).

Now, you might say, "who cares about those edge cases; just give me the simple implementation that works most of the time." But that's also how Nullable started out, and it turns out people cared enough about the edge cases to go in and add support for them. Since we already know that the demand exists, it seems prudent to have v3's Option support these edge cases from the beginning.

On Friday, 28 February 2025 at 11:51:47 UTC, Paul Backus wrote:

In my view Nullable is fundamentally wrong (I have to call nullify() - whaaaat?), and if something else is based on something that is fundamentally wrong, it will most likely also be fundamentally wrong.

I mean no disrespect, I am giving you an honest opinion here. I do not use Nullable simply because I can't assign null to it - it simply does not make sense to use something with name 'Nullable' and not being able to assign null to it, so I do not use it. I will most likely have the same issue with Option!T, judging from your last reply...

On Friday, 28 February 2025 at 12:22:29 UTC, Dejan Lekic wrote:

I agree that the name Nullable is fundamentally wrong for what Nullable does. That's why the name is being changed to Option in Phobos v3.

If what you are looking for is something that keeps the name Nullable, but changes the functionality to allow assigning null, then Option will not be what you want.

On Friday, 28 February 2025 at 12:22:29 UTC, Dejan Lekic wrote:

Also, to be clear, Option is not really "based on" Nullable; it is a ground-up redesign and rewrite based on the concept of an option type, which appears in several other languages.

On Friday, 28 February 2025 at 00:13:42 UTC, Paul Backus wrote:

If nothing else, this is great just to avoid the awful debugging experience of using match.

This may not be the best place to ask, but are sum types still planned to become a language feature?

On Friday, 28 February 2025 at 11:33:50 UTC, Dejan Lekic wrote:

a nullable!ubyte has 257 states, its 2 values.

On Friday, 28 February 2025 at 15:54:54 UTC, monkyyy wrote:

Yep. In mir nullable!t is just algebraic!(typeof(null),t), and it makes absolute sense.

On Friday, 28 February 2025 at 19:28:04 UTC, Sebastiaan Koppe wrote:

Thats 2 types, thats not quite what I mean, I do mean 2 values
Theres tradeoffs, if you are only planning on all sumtypes to be exactly taggedunions and nullable, a lazy overload seems defensible but there are trade offs thats making.

On Friday, 28 February 2025 at 20:15:31 UTC, monkyyy wrote:

I don't understand what you mean with 2 values. nullable!ubyte has one value which is potentially absent, which is not the same as having 2 bytes.

Implementation is free to encode it is 2 bytes of course.