https://issues.dlang.org/show_bug.cgi?id=23987
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from [email protected] --- (This is an enhancement request, not a bug report.) Taking the address of `p` in your example is not `@safe` (and subsequently the pointer in your main function refers to a dead memory location, as the value after implicit conversion is separate from the one before implicit conversion). This enhancement request grew out of the existing behavior being confusing. In particular: ```d import std.typecons; struct T { // no copy constructor } struct S { this(const ref S _){ // dummy copy constructor } } void main(){ Nullable!T t; // ok Nullable!S s; // error } ``` The error happens here: ```d this(ref return scope inout Nullable!T rhs) inout { _isNull = rhs._isNull; if (!_isNull) _value.payload = rhs._value.payload; else _value = DontCallDestructorT.init; } ``` I had hoped we can avoid the requirement for people to provide an `inout` copy constructor if they are generating a mutable `struct` without indirections from a `const` instance. However, I agree that generating an implicit second copy constructor call to a generated copy constructor after the user has already provided their own copy constructor is probably even worse because copies/moves may get missed. Maybe requiring the copy constructor to be annotated `pure` is good enough, but the overall situation is a bit unsatisfactory. Closing this for now. --
