Hiding class pointers -- was it a good idea?

[Reiner Pope]

Bill Baxter wrote:
> I'm starting to seriously wonder if it was a good idea to hide the 
> pointers to classes.  It seemed kinda neat when I was first using D that 
> I could avoid typing *s all the time.  But as time wears on it's 
> starting to seem more like a liability.
> 
> Bad points:
> - Harder to tell whether you're dealing with a pointer or not
>   (c.f. the common uninitialized 'MyObject obj;' bug)
> - To build on the stack, have to use 'scope'
> 
> Good points:
> + No need to type '*' everywhere when you use class objects
> + ??? anything else ???
> 
> 
> I guess I feel like that if D were Java, I'd never see the pointers, 
> "Foo foo;" would always mean a heap-allocated thing, and everything 
> would be cool. But with D sometimes "Foo foo" means a stack allocated 
> thing, and sometimes it doesn't.  I'm starting to think the extra 
> cognitive load isn't really worth it.
> 
> In large part it all stems from the decision to make classes and structs 
> different.  That seems nice in theory, but as time goes on the two are 
> becoming more and more alike.  Classes can now be stack-allocated with 
> scope.  Structs are supposedly going to get constructors, and maybe even 
> destructors.  It kind of makes me think that maybe separating structs 
> and classes was a bad idea.  I have yet to ever once say to myself 
> "thank goodness structs and classes are different in D!", though plenty 
> of times I've muttered "dangit why can't I just get a default copy 
> constructor for this class" or "shoot, these static opCalls are 
> annoying" or "dang, I wish I could get a weak reference to a struct", etc.
> 
> --bb

How about allowing operator overloads on classes which must be treated 
as reference types?

ByValue* a;
// can't overload opAdd usefully:
assert(a.opAdd(5) != a + 5);

ByRef b;
// but we can if the pointer is hidden
assert(b.opAdd(5) == a + 5);

   -- Reiner