The overloaded opAssign in SysTime makes it unusable with Nullable in structs that have invariants that fail on T.init and hence @disable this().

struct S
{
  SysTime st_;

  int i;
  invariant { assert(i > 0); }
  this(int i) { this.i = i; }
  @disable this(); // S() is not a valid S
}

Nullable!S ns;
^ this fails - SysTime has opAssign and could thus observe the invalid .init state.

Nullable!T is constructable in one of two cases: first, if T() is a valid value of T, in which case the Nullable can initialize its member to T(),
and second, if T does not overload opAssign, in which case there is no way for it to notice its invalid state.
SysTime overloads opAssign, so S overloads opAssign, so S's opAssign call would trigger the invariant.
So S is unusable in Nullables, all because SysTime has opAssign.

Which is ...

why?

Augh, nevermind, it's immutable TimeZone. TimeZone needs to be immutable for some reason, so it needs Rebindable, so SysTime has opAssign anyways, because there's no native way to specify a tailconst for class references.

Augh.

Maybe it's finally time to write an emplace-based version of Nullable?

On Wednesday, 27 June 2018 at 12:49:20 UTC, FeepingCreature wrote:
> Maybe it's finally time to write an emplace-based version of Nullable?

Having done so: is it better to have just the moveEmplace Nullable, or use standard opAssign for implicitly constructable types? This would let Nullable handle horrible things like structs that do things with pointers to their members. On the other hand, it's extra complexity.

Branch here: https://github.com/dlang/phobos/compare/master...FeepingCreature:Nullable-use-moveEmplace

Comments?