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