what was wrong with struct & class in C++?

[Bill Baxter]

Walter Bright wrote:
> Christopher Wright wrote:
>> That would be allowed in D, if you could overload T.opAssign(T).
> 
> C++ still has well-known slicing problems, even with overloading 
> assignment.
> 
> The question is not "can this be done", it's more "is there a compelling 
> reason to support such behavior". I think the answer is no. Do you 
> really want a language where a class designer feels compelled to define 
> an opassign overload, then make it private to prevent people from using 
> the class as a value type? Where the base class designer needs to know 
> what the derived classes are doing so he can make the destructor virtual 
> or not? Where you cannot have arrays of base classes?

At least C++ lets you control copying behavior completely in all 
circumstances.  And documents what you are supposed to do clearly. 
Right now D gives you the choice of

1) [structs] copy by value only, with no option to customize or 
intercept copy operations
2) [classes] no defined copy behavior whatsoever

1) makes interesting ref counting wrappers etc impossible, but I think 
you're planning to fix that one.

I think 2) is a problem also.  It means that developers will each come 
up with their own way to copy objects because there's no clear way to do 
it.  I think some particular scheme should be crowned, like any class 
that wants to be copyable should provide a the pair of methods dup(), 
and copy(ThisType).  And maybe there should be something in Object to 
this effect also, even if they don't do much of anything.  Looks like 
java implements a clone() method in the base Object class.  But it looks 
like that just makes it so you get a runtime exception if the class 
you're trying to clone doesn't support cloning.  That doesn't seem like 
an improvement over a compile time error.

So I'm not really sure what should be done, but I definitely think 
something should be done to specify "the D way" to polymorphically copy 
objects.  Built-ins mostly have .dup properties, but I don't think the 
spec actually says anywhere that user classes that want to be copyable 
should have a .dup.  But even specifying a .dup is not enough I think, 
because if I derive from some class A, I have to create my derived 
class, then get class A to copy the A parts of the new object somehow, 
say via a method like A.copy(A copy_from).

C++ may have problems regarding copying classes, but D's solution is 
effectively to just remove the C++ functionality good and bad.  Ok the 
slicing problem is gone, but so is copying.  There should be one obvious 
way to make classes in D copyable, whether it be enforced by the 
language, compiler, or simply the spec and D community.

--bb