This code works:

struct None {}

struct Option(T) {
    bool hasSome;
    T value;

    this(None) {}

    this(T v) {
        hasSome = true;
        value = v;
    }
}

Option!int a = 123;    // automatically constructs an Option!int from a bare int
Option!int b = None(); // same as above but with None

but this doesn't:

Option!int something() {
  return None(); // Error: cannot implicitly convert expression `None()` of type `None` to `Option!int`
}

This kind of prevents ergonomic code like the above. Instead you have to use a function like Option!T None(T)() => Option!T() and then you have to repeat yourself with return None!int and etc... it's quite annoying :(

In C++ you may do this fairly easily, but of course there are various pitfalls because it's C++. But at least you can opt out with explicit most of the time.

Thanks in advance!

On Thursday, 1 August 2024 at 07:25:53 UTC, Emma wrote:

struct None {}

struct Option(T) {
    bool hasSome;
    T value;

    this(None) {}

    this(T v) {
        hasSome = true;
        value = v;
    }
}

Option!int a = 123;    // automatically constructs an Option!int from a bare int
Option!int b = None(); // same as above but with None

Option!int something() {
  return None(); // Error: cannot implicitly convert expression `None()` of type `None` to `Option!int`
}

I’m pretty sure this is intentional to prevent ambiguity, but I can’t quite remember what the point of that is. You can always just write the constructor manually, but yes it’s a hassle. I wonder how open people would be to changing this restriction?

P.S. You might want to put value = void, otherwise it’ll always be default-constructed. Phobos also has Nullable if you want another implementation for reference.

On Thursday, 1 August 2024 at 08:46:00 UTC, IchorDev wrote:

The problem would be that sorting the candidates of an overload set would be more complicated. Also in certain cases it would be less obvious to get which one is selected.

On Thursday, 1 August 2024 at 09:55:08 UTC, user1234 wrote:

Please elaborate about how this would interact with function overloads at all? The function has the same parameters, same return type, same attributes… what’s different exactly?

On Thursday, 1 August 2024 at 07:25:53 UTC, Emma wrote:

Option!int something() {
  return None(); // Error: cannot implicitly convert expression `None()` of type `None` to `Option!int`
}

For the program you've written, I'm happy it doesn't compile, because a lot of the time the compiler would be making buggy code compile - though I would love to have a way to do it explicitly. In this case you can change your definition of None to use alias this and it will compile:

struct None {
    alias convert this;

    Option!int convert() {
        return Option!int(None());
    }
}

On Thursday, 1 August 2024 at 10:59:03 UTC, IchorDev wrote:

That was a general criticism of implicit construction. The classic example is

struct S {int i;}
function f(S s);
function f(int i);

unittest { f(0); } // both match

unless the idea would rather be to allow implicit construction only in the context of initialization.

On Thursday, 1 August 2024 at 08:46:00 UTC, IchorDev wrote:

Doing = void can violate the assumptions of a destructor of T. Nullable uses a union to store T, so it can decide when to call the destructor.

Thanks everyone for the replies! I just thought it was weird that implicit construction is seemingly supported when directly initialising a struct but not in any other case. I guess it's because it's clearly less ambiguous.

On Thursday, 1 August 2024 at 13:07:09 UTC, Lance Bachmeier wrote:

The alias this doesn't work generically, though. Either way I agree that implicit construction, if it was present in D, should not be the default, instead being opt-in like say through an implicit this(...) or whatever instead of C++'s horrendous implicit by default behaviour.