www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What would break if class was merged with struct

reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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?
May 27
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
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.
May 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
May 27
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
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.
May 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
May 27
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
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.
May 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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)?
May 27
next sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
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.
May 27
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
May 27
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 27 May 2017 at 17:24:14 UTC, Ola Fosheim Grøstad 
wrote:
 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.
Then please don't call them "smart", because that term is specifically reserved for something that adds at least some additional features over a regular pointer (bounds checking, memory / lifetime management, etc.).
May 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 27 May 2017 at 18:21:41 UTC, Moritz Maxeiner wrote:
 Then please don't call them "smart", because that term is 
 specifically reserved for something that adds at least some 
 additional features over a regular pointer (bounds checking, 
 memory / lifetime management, etc.).
"smart pointer" just means that it is a pointer wrapped in an ADT. In this context it could provide allocation-information would be one thing it could provide, or reference counting, member access or whatever. The "smart" part was deliberately left unspecified.
May 27
parent Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 27 May 2017 at 18:33:36 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 27 May 2017 at 18:21:41 UTC, Moritz Maxeiner wrote:
 Then please don't call them "smart", because that term is 
 specifically reserved for something that adds at least some 
 additional features over a regular pointer (bounds checking, 
 memory / lifetime management, etc.).
"smart pointer" just means that it is a pointer wrapped in an ADT. In this context it could provide allocation-information would be one thing it could provide, or reference counting, member access or whatever. The "smart" part was deliberately left unspecified.
An ADT that adds features to the wrapped pointer; and if it adds features, it is not *just* a normal pointer anymore, i.e. you cannot use it as a verbatim replacement for normal class instances on the language level, because you change their semantics.
May 27
prev sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
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.
Lower? No. Wrap - yes. With "scope" from DIP1000 you can even do it in a safe manner.
May 27
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 27 May 2017 at 17:28:47 UTC, Stanislav Blinov wrote:
 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.
Lower? No. Wrap - yes. With "scope" from DIP1000 you can even do it in a safe manner.
Maybe I was not clear: Of course you can put a class reference inside a struct, or even simulate a class using a rewriting mechanism, but you *cannot* use a smart pointer as a replacement for a class instance, because the latter is normal pointer, and the former adds features on top of a pointer; they cannot be the same as a matter of definition, i.e. you cannot replace classes with smart pointer structs on the language level, because it removes features from the language.
May 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 27 May 2017 at 18:26:07 UTC, Moritz Maxeiner wrote:
 mechanism, but you *cannot*  use a smart pointer as a 
 replacement for a class instance, because the latter is normal 
 pointer, and the former adds features on top of a pointer; they 
 cannot be the same as a matter of definition, i.e. you cannot 
 replace classes with smart pointer structs on the language 
 level, because it removes features from the language.
I am not sure what you mean here. As long as the "smart pointer" is in a subtype relationship with the current "class reference" then it can add features, yes? You could do this as a compiler configuration even, switch out GC with ref-counting smart pointers. The point of this thread was to have fewer language constructs, with more lowering, so that the resulting language would be a super-language, that fully covers the original language (or close to it).
May 27
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 27 May 2017 at 18:42:02 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 27 May 2017 at 18:26:07 UTC, Moritz Maxeiner wrote:
 mechanism, but you *cannot*  use a smart pointer as a 
 replacement for a class instance, because the latter is normal 
 pointer, and the former adds features on top of a pointer; 
 they cannot be the same as a matter of definition, i.e. you 
 cannot replace classes with smart pointer structs on the 
 language level, because it removes features from the language.
I am not sure what you mean here. As long as the "smart pointer" is in a subtype relationship with the current "class reference" then it can add features, yes?
An example, then: --- module a; class Foo {} module b; import a; void bar(Foo foo) {} --- Here, `bar`, takes a (pointer to a) class instance as parameter `foo`. `foo` is a single pointer, i.e. 8 bytes on a 64bit OS, with *no* special semantics. You cannot replace the meaning of type `Foo` here with something that is not also exactly 8 bytes (on 64bit OS) with no special semantics, because that changes the semantics of `bar`. i.e. `Foo` must not be a smart pointer because a smart pointer necessarily introduces features (and thus changes the semantics). And this is exactly what you were proposing in the sentence I replied to; you were proposing to essentially change the semantics of every use of a class instance in all D code by rewriting `Foo` into a smart pointer.
 The point of this thread was to have fewer language constructs,
And my reply was "if you want to do this, it must use a normal pointer, not a smart pointer, because that changes semantics". If you want a smart pointer, use one, but don't suddenly make something that isn't a smart pointer by language design change shape into a smart pointer.
 with more lowering, so that the resulting language would be a 
 super-language, that fully covers the original language (or 
 close to it).
Sure, but then type `Foo` in the above must remain a normal pointer, not become a smart pointer.
May 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 27 May 2017 at 19:01:12 UTC, Moritz Maxeiner wrote:
 Here, `bar`, takes a (pointer to a) class instance as parameter 
 `foo`. `foo` is a single pointer, i.e. 8 bytes on a 64bit OS, 
 with *no* special semantics.
Does the language spec say anything about the size of class references?
 If you want a smart pointer, use one, but don't suddenly make 
 something that isn't a smart pointer by language design change 
 shape into a smart pointer.
Is it specified? The common implementation uses a GC, but does it say that an implementation cannot use a reference counted smart pointer or a fat pointer instead?
 Sure, but then type `Foo` in the above must remain a normal 
 pointer, not become a smart pointer.
That really depends on the definition of the language.
May 27
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 27 May 2017 at 19:26:50 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 27 May 2017 at 19:01:12 UTC, Moritz Maxeiner wrote:
 Here, `bar`, takes a (pointer to a) class instance as 
 parameter `foo`. `foo` is a single pointer, i.e. 8 bytes on a 
 64bit OS, with *no* special semantics.
Does the language spec say anything about the size of class references?
Yes, is is defined as `ptrsize` and must have the exact same size as a pointer to a struct and - more importantly - a pointer to a stack frame[1].
 If you want a smart pointer, use one, but don't suddenly make 
 something that isn't a smart pointer by language design change 
 shape into a smart pointer.
Is it specified?
Yes, see above link. Unless you make *all* stack frame pointers smart pointers (which makes no sense whatsoever), class instances cannot be smart pointers in the language as it is specified right now.
 The common implementation uses a GC, but does it say that an 
 implementation cannot use a reference counted smart pointer or 
 a fat pointer instead?

 Sure, but then type `Foo` in the above must remain a normal 
 pointer, not become a smart pointer.
That really depends on the definition of the language.
Sure, and the definition requires it. [1] https://dlang.org/spec/abi.html#delegates
May 27
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 27 May 2017 at 20:24:26 UTC, Moritz Maxeiner wrote:
 On Saturday, 27 May 2017 at 19:26:50 UTC, Ola Fosheim Grøstad 
 wrote:
 On Saturday, 27 May 2017 at 19:01:12 UTC, Moritz Maxeiner 
 wrote:
 Here, `bar`, takes a (pointer to a) class instance as 
 parameter `foo`. `foo` is a single pointer, i.e. 8 bytes on a 
 64bit OS, with *no* special semantics.
Does the language spec say anything about the size of class references?
Yes, is is defined as `ptrsize` and must have the exact same size as a pointer to a struct and - more importantly - a pointer to a stack frame[1].
Huh? You are talking about lambdas? Didnt find anything on class references in that Intel specific ABI, which appears to be optional anyway.
 Yes, see above link. Unless you make *all* stack frame pointers 
 smart pointers (which makes no sense whatsoever), class 
 instances cannot be smart pointers in the language as it is 
 specified right now.
I don't understand. Why are frame pointers relevant for class references?
 Sure, and the definition requires it.
Why?
May 27
prev sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 27 May 2017 at 20:24:26 UTC, Moritz Maxeiner wrote:
 Sure, and the definition requires it.

 [1] https://dlang.org/spec/abi.html#delegates
Please note that an ABI is an implementation specific linkage detail, it cannot be portable so it does not define language semantics.
May 27
prev sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
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?
May 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 27 May 2017 at 17:22:02 UTC, Stanislav Blinov wrote:
 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?
I don't understand this argument, why would this be more difficult for D than C++? You lower class into struct (with virtual, interfaces, whistles and bells) and retain reference semantics by making it unavailable for D-move-semantics.
 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.
Huh?
 If that were true, we wouldn't even need the "extern(C++)", 
 would we?
Sounds more like an implementation detail to me.
May 27
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Saturday, 27 May 2017 at 17:30:49 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 27 May 2017 at 17:22:02 UTC, Stanislav Blinov 
 wrote:
 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?
I don't understand this argument, why would this be more difficult for D than C++?
Perhaps it wouldn't be if we were talking about new language. With D, such a change falls out of "some language changes, a bit of automated source updating and a little bit of breakage", and becomes "whole language change, a rewrite of runtime and standard library, and breaking every single project that uses D today". Or did we leave behind your original question?
 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.
Huh?
Yes.
 If that were true, we wouldn't even need the "extern(C++)", 
 would we?
Sounds more like an implementation detail to me.
:) Everything is an "implementation detail".
May 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 27 May 2017 at 18:06:11 UTC, Stanislav Blinov wrote:
 Perhaps it wouldn't be if we were talking about new language.
 With D, such a change falls out of "some language changes, a 
 bit of automated source updating and a little bit of breakage", 
 and becomes "whole language change, a rewrite of runtime and 
 standard library, and breaking every single project that uses D 
 today".
 Or did we leave behind your original question?
No. I am talking about language semantics. Are the semantics for class and struct conflicting or can they be merged? That is the question. I am talking about the language, as specified, not the implementation.
 Yes.
Huhhh?? :^)
 :) Everything is an "implementation detail".
No... No... No...
May 27
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Saturday, 27 May 2017 at 18:13:52 UTC, Ola Fosheim Grøstad 
wrote:

 Or did we leave behind your original question?
No. I am talking about language semantics. Are the semantics for class and struct conflicting or can they be merged? That is the question. I am talking about the language, as specified, not the implementation.
Ahem. As specified, classes are reference types, struct aren't. What more is there to say?
May 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 27 May 2017 at 18:44:03 UTC, Stanislav Blinov wrote:
 On Saturday, 27 May 2017 at 18:13:52 UTC, Ola Fosheim Grøstad 
 wrote:

 Or did we leave behind your original question?
No. I am talking about language semantics. Are the semantics for class and struct conflicting or can they be merged? That is the question. I am talking about the language, as specified, not the implementation.
Ahem. As specified, classes are reference types, struct aren't. What more is there to say?
Structs are reference types too. The specification is wrong.
May 27
parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Saturday, 27 May 2017 at 18:44:42 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 27 May 2017 at 18:44:03 UTC, Stanislav Blinov 
 wrote:
 On Saturday, 27 May 2017 at 18:13:52 UTC, Ola Fosheim Grøstad 
 wrote:

 Or did we leave behind your original question?
No. I am talking about language semantics. Are the semantics for class and struct conflicting or can they be merged? That is the question. I am talking about the language, as specified, not the implementation.
Ahem. As specified, classes are reference types, struct aren't. What more is there to say?
Structs are reference types too. The specification is wrong.
I've seen this argument from you before, and it's incorrect. Structs may adopt reference semantics if they aggregate pointers, that's true. But they are not themselves reference types. Their representation is laid out inline. Classes, OTOH, are always references, to get at their memory you need an indirection. Thus, if we were to merge classes and structs, we'd have to pick one or the other.
May 27
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 27 May 2017 at 18:56:47 UTC, Stanislav Blinov wrote:
 I've seen this argument from you before, and it's incorrect. 
 Structs may adopt reference semantics if they aggregate 
 pointers, that's true. But they are not themselves reference 
 types. Their representation is laid out inline.
This is the ACID test: Values have no identity. An instance of a struct has an identity. Allocation is another issue. A stack allocation is just an optimization of a heap allocation. Many languages put all the activation records (stack frames) on the heap. This is very useful for high levels of concurrency.
 Classes, OTOH, are always references, to get at their memory 
 you need an indirection. Thus, if we were to merge classes and 
 structs, we'd have to pick one or the other.
Structs are more general, so you don't have to pick anything, you just add the class features to the struct. That means the minimal core language no longer have the class concept. The full language with lowering (syntactical sugar) still has the class concept since it can be covered by struct + "smart pointer" + modified new.
May 27
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 27 May 2017 at 20:13, Ola Fosheim Grøstad via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Saturday, 27 May 2017 at 18:06:11 UTC, Stanislav Blinov wrote:
 Perhaps it wouldn't be if we were talking about new language.
 With D, such a change falls out of "some language changes, a bit of
 automated source updating and a little bit of breakage", and becomes "whole
 language change, a rewrite of runtime and standard library, and breaking
 every single project that uses D today".
 Or did we leave behind your original question?
No. I am talking about language semantics. Are the semantics for class and struct conflicting or can they be merged?
The semantic difference is that structs are POD records, and classes are references (or pointers) to GC heap with inheritance (underlying record includes fields from base classes). For ABI, structs are compatible with C (this is documented as per spec), and classes underlying records are compatible with C++ (don't think this is documented, but it's certainly assumed). Focusing on the latter point, this means that the following declarations: struct Something { int a; long b; char c; } class Something { int a; long b; char c; } are identical to each other, apart from the latter getting a __vptr and __monitor field. However, for extern(D) classes, there's actually nothing stopping a D compiler implementer from making class types more memory efficient, an optimizing compiler could decide to re-arrange class fields as: class Something { long b; int a; char c; } After all, we only need extern(D) to be compatible with ourselves, not other languages. As a side note, when I talked about D at the GNU Hackers Meeting a number of years back, when I said that structs and classes are two distinct types - one being POD-only, the other being a reference that comes with the bells and whistles of OOP - I actually got a small cheer. This gives me a very strong impression of what C++ programmers think of their own situation regarding struct vs class, and that we should not be so eager to follow their design.
May 28
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 28 May 2017 at 09:09:39 UTC, Iain Buclaw wrote:
 However, for extern(D) classes, there's actually nothing 
 stopping a D compiler implementer from making class types more 
 memory efficient, an optimizing compiler could decide to 
 re-arrange class fields as:

     class Something
     {
         long b;
         int a;
         char c;
     }
Yes, but you could do that for structs as well, after static analysis establishing that it no code in this specific program is making assumptions about layout. Or you could have an attribute that says that that field X should be at byte-offset N, but all other fields can move.
 As a side note, when I talked about D at the GNU Hackers 
 Meeting a number of years back, when I said that structs and 
 classes are two distinct types - one being POD-only, the other 
 being a reference that comes with the bells and whistles of OOP 
 - I actually got a small cheer.  This gives me a very strong 
 impression of what C++ programmers think of their own situation 
 regarding struct vs class, and that we should not be so eager 
 to follow their design.
Did they explain why? Many other languages provide a single construct with far more wide-ranging features than D/C++. For generic programming it is generally better to have fewer constructs, but you might need a way convenient way to express constraints (i.e. C++ concepts).
May 28
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 28 May 2017 at 13:30, Ola Fosheim Grøstad via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Sunday, 28 May 2017 at 09:09:39 UTC, Iain Buclaw wrote:
 However, for extern(D) classes, there's actually nothing stopping a D
 compiler implementer from making class types more memory efficient, an
 optimizing compiler could decide to re-arrange class fields as:

     class Something
     {
         long b;
         int a;
         char c;
     }
Yes, but you could do that for structs as well, after static analysis establishing that it no code in this specific program is making assumptions about layout. Or you could have an attribute that says that that field X should be at byte-offset N, but all other fields can move.
 As a side note, when I talked about D at the GNU Hackers Meeting a number
 of years back, when I said that structs and classes are two distinct types -
 one being POD-only, the other being a reference that comes with the bells
 and whistles of OOP - I actually got a small cheer.  This gives me a very
 strong impression of what C++ programmers think of their own situation
 regarding struct vs class, and that we should not be so eager to follow
 their design.
Did they explain why? Many other languages provide a single construct with far more wide-ranging features than D/C++.
I said it all in one breath, so you could leave it up to interpretation whether they applauded the fact that there is a separation in semantics, or whether there is no multiple inheritance in D (except via interfaces). When asking one person over dinner later about what they felt was wrong about struct/class in C++, I got the impression that because there's almost no distinction between the two, class seems more like a misfeature of C++. You could say that C++ should have stuck to one type, instead of having two. And because in D we make a very clear distinction, that justifies the reason to have both struct and class.
May 28
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 28 May 2017 at 12:31:35 UTC, Iain Buclaw wrote:
 I said it all in one breath, so you could leave it up to 
 interpretation whether they applauded the fact that there is a 
 separation in semantics, or whether there is no multiple 
 inheritance in D (except via interfaces).

 When asking one person over dinner later about what they felt 
 was wrong about struct/class in C++, I got the impression that 
 because there's almost no distinction between the two, class 
 seems more like a misfeature of C++.
Well, class and struct is semantically the same in C++. The only difference is that you don't have private and protected on structs. So the distinction is historical, to quote cppreference.com: «The keywords are identical except for the default member access and the default base class access.»
 You could say that C++ should have stuck to one type, instead 
 of having two.
Struct and class is one type in C++. The difference is in the syntax where the grammar does not allow access protection for the struct keyword. So not semantical, but syntactical.
 And because in D we make a very clear distinction, that 
 justifies the reason to have both struct and class.
But you don't make a very clear distinction in D. If struct was a pure value type and mapped to pure valued tuples, then you might have a justification for it. From a type-system point of view the distinction makes no sense to me.
May 28
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 28 May 2017 at 14:30:00 UTC, Ola Fosheim Grøstad wrote:
 Struct and class is one type in C++. The difference is in the 
 syntax where the grammar does not allow access protection for 
 the struct keyword. So not semantical, but syntactical.
I.e. you can just search-and-replace "struct" with "class" in C++ and it will behave the same way. "struct" is only used as a mnemonic device...
May 28
prev sibling next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Saturday, May 27, 2017 16:37:04 Ola Fosheim Grstad via Digitalmars-d 
wrote:
 Monitor (i.e. for "synchronized") and
Wasn't this going to be removed?
There was definitely talk of doing it, but it's never actually happened. I don't think that it was actually decided that we would though, and some other things that we _definitely_ decided we do have never actually happened either (e.g. remove delete from the language and remove toString, toHash, opCmp, and opEquals from Object). Getting major changes in is often something that doesn't work out very well given the obstacles involved. I don't recall what the obstacles to getting the monitor changes in where, but I suspect that in order to get them in, someone would effectively have to champion the changes and push them through, and while I think that there was someone trying to do that at one point, they seem to have given up on it. I don't know if they ran into insurmountable problems or simply gave up and left. But as long as D classes have a built-in monitor, then that's one of the key differences between a D class or struct (or a D and C++ class for that matter). - Jonathan M Davis
May 27
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 27 May 2017 at 20:34, Jonathan M Davis via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Saturday, May 27, 2017 16:37:04 Ola Fosheim Grøstad via Digitalmars-d
 wrote:
 Monitor (i.e. for "synchronized") and
Wasn't this going to be removed?
There was definitely talk of doing it, but it's never actually happened. I don't think that it was actually decided that we would though, and some other things that we _definitely_ decided we do have never actually happened either (e.g. remove delete from the language and remove toString, toHash, opCmp, and opEquals from Object). Getting major changes in is often something that doesn't work out very well given the obstacles involved.
There's nothing blocking the deprecation of monitors. Just someone needs to do the work.
May 28
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 27 May 2017 at 16:12, Ola Fosheim Grøstad via Digitalmars-d
<digitalmars-d puremagic.com> 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?
Strictly speaking, this already is the case. Something sth = new Something (...); all that is really doing is just: struct Something* sth = new Something (...); You just aren't exposed this in the language.
May 28
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 28 May 2017 at 08:24:50 UTC, Iain Buclaw wrote:
 Strictly speaking, this already is the case.

     Something sth = new Something (...);

 all that is really doing is just:

     struct Something* sth = new Something (...);

 You just aren't exposed this in the language.
Right, but since the language now is more powerful than it was in D1, it should be possible to implement class references as a templated struct, right? So there is no longer a need for this special casing of class vs struct. The only thing you need to do is modify "new" to recognize it. I think?
May 28