Why is separating class ind struct is bad?

[Dicebot via Digitalmars-d]

On 03/26/2016 02:01 PM, Walter Bright wrote:
> 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.

It is hard to argue that but I have never encountered any issues from
actual confusion between struct and class in C++ (because there isn't
any real difference), only from misusage of virtual types.

>> 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.

I'd prefer to do lot of editing as opposed to lot of reading through to
not introduce silent semantical bugs - which is exactly how switching
between struct and class looks now. This is a major benefit, not an issue.

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

No way. `typedef int* p_int_t` is one of worst popular C idioms in my
opinion. Typing extra three letters is a very minor price for having a
code which looks like what it does.

> 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.

MyClass* should also be applicable, I have only mentioned `ref` because
non-escpaing is usually desired :) Btw implementation of DIP25 is
heavily incomplete, I have never managed to make it work in any of
practical attempts. There are quite some bug reports open :
https://issues.dlang.org/buglist.cgi?quicksearch=dip25&list_id=207387

> 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.

Well, languages that simply declare everything a reference (JS) or
dropped support for inheritance based polymorphism (Go, Rust) are much
more consistent in that regard in my opinion :)

There isn't much point in discussin details at this point as the ship
has long sailed. But I definitely consider this one of underdesigned
parts of D language.