[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