https://issues.dlang.org/show_bug.cgi?id=17440

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
>From the docs: "The nullable struct defines a value paired with a null.". I
think that the expectation is that nullable is used with value types, not reference types or variables of references.

--

https://issues.dlang.org/show_bug.cgi?id=17440

--- Comment #2 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
(In reply to Marenz from comment #0)
> I am not sure if it is desired, but it was highly unintuitive and unexpected for me:
> 
> If you use Nullable with a class type and call .nullify(), all members of the class are set to the uninitialized state. Example:

That is almost certainly not intended, and (as RazvanN wrote) is because the Nullable implementation makes no attempt to do anything different when used with a class. What happens is that it calls object.destroy on the class, which instead of setting the class reference to null, it clobbers the class data.

However, I think your example is also incorrect, because it accesses the value of a nullified object.

Is there any particular reason you need to use Nullify with a class type instead of simply using the class type directly and use "null" to indicate the unset state?

--

https://issues.dlang.org/show_bug.cgi?id=17440

--- Comment #3 from Marenz <dmdtracker@supradigital.org> ---
>Is there any particular reason you need to use Nullify with a class type instead of simply using the class type directly and use "null" to indicate the unset state?

There is no pressing need to do this.
I am having a special array class that wraps every member in a Nullable and of
course it's templated.

So I needed to add a special overload/case for class types to work around that.

It's less a 'need' but more a 'this was very unexpected'.

--

https://issues.dlang.org/show_bug.cgi?id=17440

--- Comment #4 from RazvanN <razvan.nitu1305@gmail.com> ---
Eveyone ok with closing this?

--

https://issues.dlang.org/show_bug.cgi?id=17440

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--

https://issues.dlang.org/show_bug.cgi?id=17440

--- Comment #5 from Marenz <dmdtracker@supradigital.org> ---
Closing? Well.. It is _very_ unexpected that Nullable would just follow a reference and kills everything. It's like you add a pointer to an array and after setting it to null your pointed object is also reset.

While this is not a terrible problem to work around, it is quite inconsistent and surprising behavior and I think this should really be fixed.

Do you really want to have such behavior in the std lib?

--

https://issues.dlang.org/show_bug.cgi?id=17440

--- Comment #6 from RazvanN <razvan.nitu1305@gmail.com> ---
(In reply to Marenz from comment #5)
> Closing? Well.. It is _very_ unexpected that Nullable would just follow a reference and kills everything. It's like you add a pointer to an array and after setting it to null your pointed object is also reset.
> 
> While this is not a terrible problem to work around, it is quite inconsistent and surprising behavior and I think this should really be fixed.
> 
> Do you really want to have such behavior in the std lib?

Nullable wasn't design for reference types. I guess that a check could be added to reject creating Nullable's from data structures that are not value types.

--

https://issues.dlang.org/show_bug.cgi?id=17440

--- Comment #7 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
Yep, deprecating Nullable for reference types seems like a reasonable idea; feel free to reopen or refile as a new enhancement.

--

https://issues.dlang.org/show_bug.cgi?id=17440

Chris Paulson-Ellis <chris@edesix.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |chris@edesix.com
         Resolution|INVALID                     |---

--- Comment #8 from Chris Paulson-Ellis <chris@edesix.com> ---
Reopening for reconsideration, because:

When using Nullable as an analogue of Java Optional or Haskell Maybe, there is no reason why you shouldn't use a reference type.

Destroying on nullify will invalidate *other* references to the object, which goes beyond the remit of Nullable.

And finally, because I was asked to submit a bug report and this one already existed. See forum discussion:

https://forum.dlang.org/thread/rglbcxolihbogsvvnser@forum.dlang.org

--

https://issues.dlang.org/show_bug.cgi?id=17440

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #9 from hsteoh@quickfur.ath.cx ---
But by-reference objects in D *already* have nullable semantics, i.e.:

-------
class C {}
C c;
assert(c is null); // c is null by default
c = new C;
assert(c !is null);
c = null; // nullify
assert(c is null);
-------

Of course the syntax is slightly different (direct use of null vs. .isNull / .nullify).  But there's really no benefit to using Nullable with reference types in D.

OTOH, if you're using generic code that expect a single API for nullable objects, perhaps the solution is to write an overload of Nullable that simply maps .isNull to `is null` and .nullify to `= null` when the wrapped type is a class.

--