Question

If my understanding is correct, the following semantics apply to structs and classes in C++, C# and D:

        struct          class
----------------------------------
C++     stack/heap      stack/heap
        value/reference value/reference

C# / D  stack           heap
        value           reference

I.e., in C++ there is no semantic difference between structs and classes (apart from the default public / private access). In contrast, C# and D structs have value semantics and stack allocation (at least by default), whereas C# and D classes have reference semantics and heap allocation.

My question is: would it be good C++ style to mimic this difference by using the struct keyword exclusively for all entities with value semantics, and the class keyword exclusively for all entities with reference semantics?

It would of course be a self-discipline tool not enforced by the compiler, but it could improve code readibility, especially for reviewers with C# / D backgrounds. OTOH, the current idiom in C++ seems to be to only use the struct keyword for simple entities such as pure POD aggregates and template metafunctions only, so it could be confusing for C++ programmers.

Answer 1

If that were the only relevant distinction, it might make sense. In
practice, there’s much more to it than that. In C++, it’s very frequent
for objects with real behavior (and which don’t support copy) to be
allocated on the stack; it also occurs from time to time that pure data
containers be allocated dynamically. C# and D are confounding two
orthogonal distinctions: arbitrary object lifetime vs. object lifetime
linked to scope, and whether the object has value semantics or not.
While it’s true that these two distinctions do coincide for some types,
it’s not an absolute rule, and imposing it at a language level creates a
straight jacket which at times prevents the use of the cleanest and most
natural solution.