Hiding class pointers -- was it a good idea?

[Deewiant]

Bill Baxter wrote:
> 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.
> 

I think the separation was a good idea. I like structs not having hidden fields,
being laid out in memory exactly as I write the code, and having no performance
overhead due to vtables, etc. In C++, the only difference is that structs
default to public while classes default to private. Where's the use in that?
Just use a class for everything - and most people do. I like my POD datatype,
thank you very much.

With that said, I agree that hiding class pointers may not have been a good
idea. Still, I can't think of many points which would make it a particularly bad
idea.

Defaulting to stack allocation somehow would be better: it's easy to write
"auto" instead of "scope" and forget about it. But then, the performance in such
cases rarely matters, and when it does, you do notice such things because you're
looking for them.

"Myobject obj;" being uninitialized is supposed to be a feature, not a bug, just
like "T t;" should be explicitly initialized for every T.

The idea is that if you forget to initialize something you get an easy-to-find
error: all chars are initialized to 0xff, so if you're wondering why you're
getting running into lots of 0xff in some output, you look for uninitialized
chars. Ditto for floating point and NaNs.

Integers don't have an "uninitialized" value so they go to zero. IMHO this
should perhaps have been made T.min or T.max instead of zero, as zero is so
common an initializer that people forget the reason why variables are
initialized by default. Walter said that even he's guilty of sometimes leaving
integers uninitialized when they should be initialized to zero, and I do it too,
but that doesn't mean that's how it should be done.

Initializers are present to catch errors by making code fail hard (as in the
"Object o;" case) instead of silently (as in if you type "int x;" in C/C++ and
proceed to increment or decrement x).

-- 
Remove ".doesnotlike.spam" from the mail address.