Hiding class pointers -- was it a good idea?

[Deewiant]

Bill Baxter wrote:
> I like my POD datatypes too.  And I like the fact that in C++ I can change
> from POD to not-POD by adding one little word to the class/struct 
> ("virtual").  Almost all code that relies on that POD type will still work if
> it gains a vtable and one or more virtual methods.  In D it's much more
> difficult.  static opCalls need to be changed to this() constructors, and
> every bit of code that uses the thing will have to be changed -- mostly
> Foo*'s will need to be changed to Foo's.  But some places may be better off
> changing to scope Foo.  So you need to look closely at the code you're
> changing.
> 

You're right, explicit virtual helps. Classes could default to virtual, and
structs to non-virtual. Now _that_ would be handy. Newbies or people who don't
care about this low-level stuff could just use classes for everything as it is
now, but struct use would be simpler.

> Put it this way, if I download someone's container library, I don't want to
> have to think about whether their CoolSet is a class or a struct in order to
> create one by value.

This I agree with. Even type inference doesn't solve this problem.

What I like about C++ is that "new" means "allocate on the heap". In D, you have
to add "unless storing as 'scope'".

> I don't think the performance is as much of an issue as consistency.

I don't see the consistency problem between stack and heap allocation.

In fact, upon further reflection, what heap allocation has going for it is that
it's more consistent: you can do "Obj o = new Obj" followed by a "return o", and
it works, just as you can do "int x = 5" followed by "return x". If stack
allocation were the default, "return o" would be a problem, because it's a
pointer to the now-invalid stack.

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