I wonder, what would break if all the features of class was merged into struct?

Imagine that:

    class Something ... { ... }

is lowered into:

    struct _class_Something ... { ... }
    alias Something = MagicClassRef!_class_Something;

Is it conceivable with some language changes, a bit of automated source updating and a little bit of breakage?

On Saturday, 27 May 2017 at 14:12:09 UTC, Ola Fosheim Grøstad wrote:
> I wonder, what would break if all the features of class was merged into struct?
>
> Imagine that:
>
>     class Something ... { ... }
>
> is lowered into:
>
>     struct _class_Something ... { ... }
>     alias Something = MagicClassRef!_class_Something;
>
> Is it conceivable with some language changes, a bit of automated source updating and a little bit of breakage?

It's not "a little bit", it's ABI down the drain, along with a good part of runtime. And we'd lose interfaces and extern(C++).

That being said, it is totally possible today to have struct wrappers over classes, both malloc'ed and stack-allocated. The problem is that destruction is always @system (due to reasons described in my "Destructor attribute inheritance" thread: http://forum.dlang.org/thread/wtxkfylodzaaifojaglr@forum.dlang.org). And one has to adopt a discipline not to escape references.

Once DIP1000 is fully realized, at least the latter part will become unnecessary.

On Saturday, 27 May 2017 at 16:04:42 UTC, Stanislav Blinov wrote:
> It's not "a little bit", it's ABI down the drain, along with a good part of runtime. And we'd lose interfaces and extern(C++).

Why would you loose interfaces and extern(C++)?

"struct" and "class" are interchangeable keywords in C++ (only affects encapsulation). So not a lot more difference than POD vs non-POD in C++?

> That being said, it is totally possible today to have struct wrappers over classes, both malloc'ed and stack-allocated.

Well, I am asking more out of a theoretical interest for what the core language in D could boil down to.

On Saturday, 27 May 2017 at 16:23:33 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 27 May 2017 at 16:04:42 UTC, Stanislav Blinov wrote:
>> It's not "a little bit", it's ABI down the drain, along with a good part of runtime. And we'd lose interfaces and extern(C++).
>
> Why would you loose interfaces and extern(C++)?
>
> "struct" and "class" are interchangeable keywords in C++ (only affects encapsulation). So not a lot more difference than POD vs non-POD in C++?

There's a lot more difference in D. Classes in D are fat memory chunks storing pointers to ClassInfo (inc. vtable), Monitor (i.e. for "synchronized") and a list of all interfaces they implement, that's before we get to data members. If we were to remove all that, we'd lose the semi-natural way of interfacing to C++ classes, and some pretty horrendous code involving void* and void** would have to be used.

On Saturday, 27 May 2017 at 16:31:32 UTC, Stanislav Blinov wrote:
> There's a lot more difference in D. Classes in D are fat memory chunks storing pointers to ClassInfo (inc. vtable),

So are classes with virtual functions in C++, to get RTTI you need to have a virtual member function. I don't see the big difference.

> Monitor (i.e. for "synchronized") and

Wasn't this going to be removed?

> a list of all interfaces they implement,

Semantically roughly the same as multiple-inheritance in C++ but more limited.

> If we were to remove all that, we'd lose the semi-natural way of interfacing to C++ classes, and some pretty horrendous code involving void* and void** would have to be used.

I don't understand what you mean here.

On Saturday, 27 May 2017 at 16:37:04 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 27 May 2017 at 16:31:32 UTC, Stanislav Blinov wrote:
>> There's a lot more difference in D. Classes in D are fat memory chunks storing pointers to ClassInfo (inc. vtable),
>
> So are classes with virtual functions in C++, to get RTTI you need to have a virtual member function. I don't see the big difference.

But structs in D have none of that.

>> Monitor (i.e. for "synchronized") and
>
> Wasn't this going to be removed?

Not that I'm aware of.

>> a list of all interfaces they implement,
>
> Semantically roughly the same as multiple-inheritance in C++ but more limited.
>
>> If we were to remove all that, we'd lose the semi-natural way of interfacing to C++ classes, and some pretty horrendous code involving void* and void** would have to be used.
>
> I don't understand what you mean here.

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

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.

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?

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.

> 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)?

On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad wrote:

>
> The class reference type should be fixable with a rewrite into templated smart pointers, so no need for big changes there, I think.

Smart pointers impose a specific object lifetime, whereas (D) classes do not. You cannot lower (D) class instances to smart pointers.

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?

On Saturday, 27 May 2017 at 17:19:48 UTC, Moritz Maxeiner wrote:
> On Saturday, 27 May 2017 at 17:02:40 UTC, Ola Fosheim Grøstad wrote:
>
>>
>> The class reference type should be fixable with a rewrite into templated smart pointers, so no need for big changes there, I think.
>
> Smart pointers impose a specific object lifetime, whereas (D) classes do not. You cannot lower (D) class instances to smart pointers.

In this context smart pointers are just pointers that aren't raw pointers, e.g. alias this or something.