Hiding class pointers -- was it a good idea?

[Bill Baxter]

Walter Bright wrote:
> Bill Baxter wrote:
>> Of course it comes at the expense of making it impossible to pass a 
>> class by value.
> 
> That is a deliberate positive feature, not an expense.

Ok.  Thanks for all the responses.

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.

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.

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.  :-)

--bb