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?
