What would break if class was merged with struct

[Stanislav Blinov via Digitalmars-d]

On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad 
wrote:
> On Saturday, 27 May 2017 at 16:52:17 UTC, Stanislav Blinov 
> wrote:
>> But structs in D have none of that.
>
> Neither does C++ if you don't add a virtual function to it, so 
> it would be the same.
>
> My question isn't whether structs have it now, but if the 
> concept struct and class could be merged. Basically, the 
> question is: are there features that are incompatible in terms 
> of semantics?

But they are incompatible precisely because structs "don't have 
it". Inheritance for one. Reference semantics for another. A 
class reference is a pointer in disguise, struct is full layout 
on the stack. The only way to retain inheritance and reference 
semantics while removing "class" keyword would be not to merge 
classes into structs, but structs into classes. And then what, 
always allocate on the heap?

> The class reference type should be fixable with a rewrite into 
> templated smart pointers, so no need for big changes there, I 
> think. The "new" construct would have to change a little bit so 
> that it instantiates the pointed-to-type and not the 
> reference-type.

Which is all possible as a library with zero language changes. 
But for that to work, classes shall remain classes and structs 
shall remain structs.

>> If your "struct _class_SomeThing" would simply describe the 
>> same memory layout of classes that we have today, then no 
>> language change is necessary, it's purely a library solution. 
>> Well... maybe we'd need to add class postblits if we wanted 
>> copying (which can also be done by hand with a library "clone" 
>> function and a "special" static __postblit function).
>
> Sure, D tries to stay compatible with C++, so that would 
> dictate the memory layout.
>
>> If not, then it gets complicated, as in order to retain an 
>> interface with C++ classes, D would either have to follow C++ 
>> ABI (he-he), or at the very least put the burden of mapping 
>> member function calls on the programmer.
>
> I thought D matched up to C++ ABI for structs/classes already 
> (gdc vs g++, ldc vs clang)?

If that were true, we wouldn't even need the "extern(C++)", would 
we?