https://github.com/D-Programming-Language/phobos/pull/1356

(In reply to comment #0)
> Currently if I want a Nullable function argument initialized to null I have to
> use:
> 
> import std.typecons: Nullable;
> void foo(Nullable!(immutable int[4]) items = Nullable!(immutable int[4]).init)
> {}
> void main() {}
> 
> 
> Or with a global helper alias:
> 
> import std.typecons: Nullable;
> alias NullableItems = Nullable!(immutable int[4]);
> void foo(NullableItems items = NullableItems.init) {}
> void main() {}
> 
> 
> But maybe there is a way to modify std.typecons.Nullable so this simpler code
> is accepted (or something equally simple):
> 
> import std.typecons: Nullable;
> void foo(Nullable!(immutable int[4]) items = null) {}
> void main() {}

I don't think that is acceptable, as you will change the behavior of Nullable!T, if "t = null" already meant something. EG:

//----
import std.typecons;

void main()
{
    auto n = Nullable!(int*)(null);
    assert(!n.isNull);
    assert(n.get() == null);
}
//----

Arguably, you won't see that very often, but it is plausible for someone to want to be able to have a nullable pointer, whose "non-null" value can itself be null.

As a workaround, Nullable-specific "null-token" could work? EG: something along the lines of:

EG:
enum Nullable {Null}

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

(In reply to comment #2)

> Arguably, you won't see that very often, but it is plausible for someone to
> want to be able to have a nullable pointer, whose "non-null" value can itself
> be null.

Hopefully I'll not see such code :-)


> As a workaround, Nullable-specific "null-token" could work? EG: something along
> the lines of:
> 
> EG:
> enum Nullable {Null}
> 
> void foo(Nullable!(immutable int[4]) items = Nullable.Null)
> {}

This seems acceptable.

https://github.com/D-Programming-Language/phobos/pull/2593

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?

(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.

(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.

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.

THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/phobos/issues/9958

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB