Bug 14477 – Nullable does not work with structs with default constructor disabled

The following simple code does not compile: -------------------------- import std.typecons; struct Foo { int x; @disable this(); this(int value) { x=value; } } void main() { Nullable!Foo foo; } -------------------------- test.d(14): Error: variable test.main.foo default construction is disabled for type Nullable!(Foo) Of course, one of the major use-cases for Nullable is to provide a way to default-initialize such a struct to a "null" state.

I see the pull-request from when this issue was filed was retracted, as this is evidently - in terms of implementation - a lot more subtle than it initially sounds. Is it really still being worked on?

Afraid not.

This is currently an issue for us, and it has been proposed we use Algebraic!Foo instead, which appears to work sufficiently, see below. What aspects are against doing it this way? The implementation of Algebraic "looks" a lot more heavyweight, but is it really, particularly in this very specific usage? If we don't like the toString behaviour, or want to have .nullify, and prefer .isNull to .hasValue, we can always make Nullable a pretty minimal wrapper... Thoughts? ----- import std.variant; import std.stdio; import std.string; struct Foo { int x; @disable this(); this(int value) { x=value; } } void main() { Algebraic!Foo foo; writeln("hasValue for default-initialized foo: %s".format(foo.hasValue)); writeln("Format default-initialized foo: %s".format(foo)); foo = Foo(5); writeln("hasValue for set foo: %s".format(foo.hasValue)); writeln("Format set foo: %s".format(foo)); foo = Algebraic!Foo(); // Nullable's foo.nullify is cooler :/ writeln("hasValue for reset foo: %s".format(foo.hasValue)); writeln("Format reset foo: %s".format(foo)); } --- output --- hasValue for unset foo: false Format unset foo: <Uninitialized VariantN> hasValue for set foo: true Format set foo: Foo(5) hasValue for unset foo: false Format unset foo: <Uninitialized VariantN>

(In reply to MichaelZ from comment #3) > This is currently an issue for us, and it has been proposed we use > Algebraic!Foo instead, which appears to work sufficiently, see below. > > What aspects are against doing it this way? More than a year of working around the issue in various ways, I looked at the Algebraic thing again: One disadvantage of Algebraic is that it doesn't have the same magical implicit .get behaviour as Nullable does :-|

Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/61d53a1ad4a64cb5d3686c3e755bcb3508ef22f6 fix Issue 14477 - Nullable does not work with structs with default constructor disabled Add unittest, improve error message a bit.

Commit pushed to stable at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/61d53a1ad4a64cb5d3686c3e755bcb3508ef22f6 fix Issue 14477 - Nullable does not work with structs with default constructor disabled