[Issue 23987] Copy construction should not disable implicit conversion
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Mon Jun 19 14:34:00 UTC 2023
https://issues.dlang.org/show_bug.cgi?id=23987
timon.gehr at gmx.ch changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |WONTFIX
--- Comment #4 from timon.gehr at gmx.ch ---
(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.
--
More information about the Digitalmars-d-bugs
mailing list