www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why does SysTime have opAssign?

reply FeepingCreature <feepingcreature gmail.com> writes:
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?
Jun 27 2018
parent reply FeepingCreature <feepingcreature gmail.com> writes:
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?
Jun 27 2018
parent FeepingCreature <feepingcreature gmail.com> writes:
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?
Jun 27 2018