Timothy Lochner

Why would that make destructors more dangerous? It seems to work okay in e.g. Rust.

Suppose I have a class that contains a handle to a ref-counted object. When the class gets destructed I want to call releaseRef(handle). Without a copy or move ctor, I could easily call releaseRef() more times than addRef().

I don't think there's a practical difference. You can implement a method that gives you a handle (and increments the ref count for you), and implement an explicit copy method that correctly copies it (with addref).

So how are you going to call releaseRef more than addRef? By memcpying it to another instance maybe, but you can do that now too so it's not really a new issue.

Think about how this stuff works in C (except with explicit destructor calls). It's easy to hide implementation so that the only way to create or copy something is through a blessed (explicit) method, when that kind of restriction is warranted.

Right, but that puts the owness on the user to know he has to make this copy() call. When writing a generic array class, you're likely going to memcpy. Or you'll provide a copy function to the array class. Or have an overloaded copy() function all classes must do.

At what point are you asking just a language-supported copy operator? (thought I guess copy assignments still exist, it's mostly a matter of whether the destination has valid initial values)

Rust has a Copy trait that you can opt into. That seems fine and could be the type of things you'd add as a consequence after you've removed the constructors. But if not.. eh, no big deal. Just write C like code. Can't copy if you only have a Foo* and don't know the size!