digitalmars.D - Why does SysTime have opAssign?
- FeepingCreature (24/24) Jun 27 2018 The overloaded opAssign in SysTime makes it unusable with
- FeepingCreature (7/7) Jun 27 2018 Augh, nevermind, it's immutable TimeZone. TimeZone needs to be
- FeepingCreature (9/11) Jun 27 2018 Having done so: is it better to have just the moveEmplace
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
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
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