On Thursday, 28 June 2018 at 18:10:07 UTC, kdevel wrote:
> On Tuesday, 26 June 2018 at 21:54:49 UTC, Jonathan M Davis wrote:
>> [H]onestly, I don't understand why folks keep trying to put nullable types in Nullable in non-generic code.
>
> How do you signify that a struct member of class type is optional?

So there're no optional type in D (ala Swift, Kotlin, Scala, etc).  There are a number of workarounds you can use to achieve the same type of behavior.

You can use ranges to denote "some" value or no value (empty range). But it's a bit inconvenient and the APIs to get that running say nothing about intent.

You can create a lightweight Maybe type: https://stackoverflow.com/questions/27241908/maybe-types-in-d

I've implemented an optional type as well that includes safe dispatching, but it's not @nogc right now -> https://github.com/aliak00/optional

I think there's another optional type on dub somewhere as well.

But using Nullable!T just defers the problem that optional solves:

if (nullable.isNull) {
  nullable.get.doSomething();
}

vs:

if (ptr !is null) {
  ptr.doSomething();
}

meh...

It's more of a tool to allow you to give any type nullability semantics.

Cheers,
- Ali

On Thursday, 28 June 2018 at 19:22:38 UTC, Jonathan M Davis wrote:
> On Thursday, June 28, 2018 18:10:07 kdevel via Digitalmars-d-learn wrote:
>> On Tuesday, 26 June 2018 at 21:54:49 UTC, Jonathan M Davis wrote:
>> > [H]onestly, I don't understand why folks keep trying to put nullable types in Nullable in non-generic code.
>>
>> How do you signify that a struct member of class type is optional?
>
> Structs aren't nullable, so wrapping them in a Nullable makes perfect sense. Whether they happen to be on the stack or members of another type is irrelevant to that. It's wrapping types like pointers and class references in a Nullable that's an odd thing to do - the types where someone might ask why the extra bool is necessary in the Nullable. Wrapping them in a Nullable makes sense in generic code, because the code isn't written specifically for them, but something like Nullable!MyClass in non-generic code is pointless IMHO, because a class reference is already nullable.
>
> - Jonathan M Davis

Reading inpput from a csv file, and the value could either be blank, na, or numeric.  Nullable!MyClass could be used to represent 3 states in your programming logic.
I'm not saying this is the best way to represent ternary states, but it's not unreasonable.

Jordan Wilson

On Thursday, June 28, 2018 19:45:52 kdevel via Digitalmars-d-learn wrote:
> On Thursday, 28 June 2018 at 19:22:38 UTC, Jonathan M Davis wrote:
> > Nullable makes sense in generic code, because the code isn't written specifically for them, but something like Nullable!MyClass in non-generic code is pointless IMHO, because a class reference is already nullable.
>
> It is already technically nullable. But how do you signify to the reader of the code that a class member in a struct or in a class may intentionally (not purely technically) be null?
>
> If I had written
>
>      class R {
>
>         S s;
>
>      }
>
> with S being a class. The reader of the code cannot spot if s is optional. In my code I could not have declared S as a struct since it implements an interface.

That's something that you have to worry about with all code involving classes. Putting Nullable on a class reference does seem like it would make it clear that you want it to be nullable, but it doesn't really, and the lack of nullable doesn't mean that it can't purposefully be null. If Nullable couldn't contain a null, or it didn't have a separate bool for null, then maybe it would help clarify, but that would result in subtle bugs in generic code whenever null is involved, and there are cases where code purposefully uses Nullable to indicate that the variable has not been initialized yet but where null is considered a reasonable value for the type. So, the fact that Nullable is there doesn't really clarify matters. It just opens up the question of what happens with null.

In my experience, it's usually pretty clear from the API or design of a piece of code whether it's intended to accept null or not (usually, the answer is no) and that folks document what happens if null is provided if it's supposed to be accepted, but regardless, any case where it's not clear needs to be documented so that it is clear. Certainly, relying on Nullable for that is going to be error-prone, because Nullable allows null and can take advantage of the fact that isNull has nothing to do with the value of null. So, if the intention is that a Nullable!MyClass never have a value of null, then that needs to be documented, essentially defeating the purpose of putting it in a Nullable in the first place. At that point, it would just be more user-friendly to let it be null and document it as such than to use Nullable and require that someone provide an uninitialized or cleared Nullable instead of just using null.

Now, some folks do use Nullable to try and handle whether a class reference is null, but given that it doesn't really solve the problem of what happens with null and still requires documenting the intent, I think that it's more misleading than enlightening to use Nullable on class references. If you're going to wrap class references to try and indicate whether they can be null or not, it makes far more sense to wrap a class reference in a wrapper intended to indicate that it _can't_ be null than one that's intended to indicate that it can be.

- Jonathan M Davis