Why is separating class ind struct is bad?

[Jonathan M Davis via Digitalmars-d]

On Saturday, March 26, 2016 08:03:21 Dicebot via Digitalmars-d wrote:
> On Saturday, 26 March 2016 at 07:42:43 UTC, Jonathan M Davis
>
> wrote:
> > So, while the separation between structs and classes definitely
> > good for D code in general
>
> I disagree with this statement. The very presence of utils like
> `Rebindable` or `scoped` indicates this wasn't a very clean
> design choice, not in a way it was implemented at least.

Rebindable is definitely a sign that there's a problem with how it was
implemented, but it's also something that we've been able to work around.
And while scoped may make sense in rare cases, pretty much by definition, if
you're putting an object on the heap, polymorphism is not involved, and
therefore it's completely unnecessary to use a class. Really, it's just an
attempt to reuse code that's in a class in a context where polymorphism is
unnecessary. So, arguably, needing scoped is a sign of bad design in the
code that's using it. Certainly, if it's needed frequently, then the types
being used with it really should have been structs.

I won't disagree that the separation of classes and structs is not without
its downsides, and the need for Rebindable does show that they way we
implemented it wasn't as elegant as it arguably should have been, but
overall, I think that the separation is a definite improvement over C++'s
approach. Unless you use scoped (which is @system), object slicing is a
non-issue thanks to that separation, and since an object that needs
polymorphism really doesn't make sense on the stack anyway, it separates
user-defined types from the inheritance mess in the cases where it's
unnecessary while still allowing inheritance to be used in a safe manner
when it makes sense.

- Jonathan M Davis