Hiding class pointers -- was it a good idea?

[Walter Bright]

Bill Baxter wrote:
> About slicing: it may be totally evil and impossible to debug when it 
> occurs, but I have to say I can't recall ever being bitten by it in 10 
> years of C++ programming.  But I tend not to go crazy with the 
> polymorphism in the first place, and if I do I guess I've been trained 
> to avoid passing by-value classes around.  Just thinking about it 
> triggers my "danger" reflex.  Always makes me queasy when I see things 
> like std::string being passed around by value even though I know that 
> most implementations are optimized to avoid copying the payload.
> And I 
> certainly would never try to assign different by-value classes to one 
> another.

The slicing problem comes about indirectly, not by directly trying to do 
such assignments.


> So yeh, you've eliminated slicing, but I'm not really convinced it was 
> such a huge problem that it warranted a syntax upheaval in the first place.

It's a well-known problem with C++, inspiring many conventions and 
idioms to avoid. I haven't myself been bitten by it either - but one of 
D's aims is to be a robust, reliable and auditable language. Trying to 
avoid such gaping holes in the type system is very important. Relying on 
convention simply is not good enough.


> But I do understand the logic that if you want polymorphic behavior you 
> _have_ to call via a reference or pointer.  And if you *always* have to 
> call via reference/pointer, then you might as well make that the default.
> 
> I think when it comes down to it the only things I'm really going to 
> have left to complain about are missing features in structs:
> 1) the lack of constructors for structs (going to be fixed),
> 2) lack of (non-polymorphic) inheritance for structs (not so major),
> 3) lack of const reference for convenient passing of structs around 
> (from what I understand the current situation in D 2.0 is that the 
> closest you can come is a const pointer to a struct, meaning that every 
> time I call the function I have to remember to dereference the args: 
> rotate(&quat,&vec).  Bleh.)
> 
> 
> Initially I unrealistically thought D's class/struct thing was going to 
> be some kind of super magic bullet, recently it dawned on me that it 
> wasn't panning out that way (hence these posts), and finally I guess I'm 
> coming to the conclusion (thanks for all the input!) that D's 
> class/struct thing is not worse than C++, but isn't necessarily better 
> than C++'s way, either.  They both have issues, just the issues are 
> shifted around.   And maybe I'll eventually come to view D's way as 
> slightly better -- esp. if the 3 issues above are sorted out ;-).  But 
> I've been permanently disabused of my illusions that separating 
> class/struct is some sort of magic cure-all.  :-)

There are plans to deal with (1) and (3), and you can do (2) using 
aggregation instead of inheritance.