Why is separating class ind struct is bad?

[Walter Bright via Digitalmars-d]

On 3/26/2016 1:03 AM, Dicebot 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.

I've worked a lot with C++ aggregates that were confused about whether they were 
a floor wax or a dessert topping, and talking to their implementors showed they 
had little idea of the consequences (and bugs) of those choices.

D's design has debatable flaws, but I'm confident they are much diminished over 
the flaws and traps in the C++ design.

 > what I would consider convenient is to limit struct/class distinction to 
polymorphism exclusively, with not extra implications. So that you can still can 
do `MyClass on_stack;` (any `MyClass` is treated as type of object) but passing 
it to function wouldn't compile unless `ref` is also used.

So where it is allocated you'd have 'MyClass' and everywhere it is used you'd 
have 'ref MyClass'. There are a lot of consequences of this, such as:

1. Want to switch between a class and a struct? You've got lots of editing to do.

2. You'd have to invent a way to do 'alias ref MyClass T;'

3. ref has special semantics in D about being a non-escaping pointer. This means 
issues if you want a 'ref MyClass' field in a struct.

I'm not saying your idea is necessarily bad, but there is a heckuva lot to think 
about in interactions with other features. It's not so easy to produce a design 
that doesn't have a nail sticking up here or there. I don't know of any language 
that succeeded in that.