Comment #0 by bearophile_hugs — 2013-03-02T12:43:34Z
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() {}
(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)
{}
Comment #3 by bearophile_hugs — 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.
Comment #4 by monkeyworks12 — 2014-10-08T01:32:57Z
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?
Comment #6 by bearophile_hugs — 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.
Comment #7 by monkeyworks12 — 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.
Comment #8 by flyboynw — 2024-11-09T04:22:45Z
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.
Comment #9 by robert.schadek — 2024-12-01T16:16:46Z