Timothy Lochner

So removing constructors would give you a _very_ different language. Some nice things would be lost, but I think overall you'd have something much better. So basically it's a sneaky way of getting a whole language redesign under the constraint of only removing 1 feature :)

Except destructors would still exist. So now copies and move ctors are gone and dtors are even more dangerous as a result.

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.