null initialization for std.typecons.Nullable

[dlangBugzillaToGithub]

bearophile_hugs reported this on 2013-03-02T12:43:34Z

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

CC List

• irritate
• monarchdodra
• monkeyworks12

Description

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() {}

[dlangBugzillaToGithub]

irritate commented on 2013-06-19T22:39:30Z

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

[dlangBugzillaToGithub]

monarchdodra commented on 2013-08-20T09:33:46Z

(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)
{}

[dlangBugzillaToGithub]

bearophile_hugs commented on 2013-08-20T13:01:04Z

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

[dlangBugzillaToGithub]

monkeyworks12 commented on 2014-10-08T01:32:57Z

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

[dlangBugzillaToGithub]

monarchdodra commented on 2014-10-08T09:47:09Z

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?

[dlangBugzillaToGithub]

bearophile_hugs commented on 2014-10-08T10:06:41Z

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

[dlangBugzillaToGithub]

monkeyworks12 commented on 2014-10-08T12:05:33Z

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