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

monkeyworks12@hotmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monkeyworks12@hotmail.com

--- Comment #4 from monkeyworks12@hotmail.com ---
https://github.com/D-Programming-Language/phobos/pull/2593

--

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

--- Comment #5 from monarchdodra@gmail.com ---
The original request was the ability to write "myNullable = null". I said this should be rejected, because "t = null" could actually be a "non-null operation".

I suggested instead using a "null-token" as a "workaround", but, as JakobOvrum states, "why all this?"

Is there something we actually *get* from this, or is it only sugar? If it's only sugar, i suggest we close. How do we close an enhancement? Won't Fix? Invalid?

--

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

--- Comment #6 from bearophile_hugs@eml.cc ---
(In reply to monarchdodra from comment #5)
> The original request was the ability to write "myNullable = null". I said this should be rejected, because "t = null" could actually be a "non-null operation".
> 
> I suggested instead using a "null-token" as a "workaround", but, as JakobOvrum states, "why all this?"
> 
> Is there something we actually *get* from this, or is it only sugar? If it's only sugar, i suggest we close. How do we close an enhancement? Won't Fix? Invalid?

Do you mean I should write code like this?

void foo(Nullable!(immutable int[4]) items = Nullable!(immutable int[4]).init)
{}

I find it not acceptable and I'd like some shorter way to write it.

--

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

--- Comment #7 from monkeyworks12@hotmail.com ---
(In reply to monarchdodra from comment #5)
> The original request was the ability to write "myNullable = null". I said this should be rejected, because "t = null" could actually be a "non-null operation".
> 
> I suggested instead using a "null-token" as a "workaround", but, as JakobOvrum states, "why all this?"
> 
> Is there something we actually *get* from this, or is it only sugar? If it's only sugar, i suggest we close. How do we close an enhancement? Won't Fix? Invalid?

Because of the design mistake in Nullable that it does not alias itself to T if T is already a nullable type, Nullable's 'null' and the wrapped type's 'null' are two different things, and it's necessary to make a distinction. One solution is to use Nullable!(...).init, but that can be inconveniently long as Bearophile pointed out. Another solution is to do `enum nullState = Nullable!(...).init`, but it's then in the global scope, and it's annoying to create a new enum for each type you want to use Nullable with. Hopefully in the future we can deprecate Nullable in lieu of an Option type and fix these little mistakes.

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P4

--

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

Adam Wilson <flyboynw@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |flyboynw@gmail.com
         Resolution|---                         |INVALID

--- Comment #8 from Adam Wilson <flyboynw@gmail.com> ---
I am closing this as "Invalid" because Nullable is not actually a nullable type but a Option type. As such this would be invalid behavior. We will rename this type in Phobos V3 to better reflect the design.

--