isocpp
Add wording for resolution #1917 and Clean up wording of C.12
The committee decision in #1917 is that:
Editors call: Thanks! We think the source of the confusion might be distinguishing between a type and an object of that type. A
constobject of a regular type is also not copy-assignable. An immutable type should just behave as though all its objects areconst. If mandating that all objects of a type are effectivelyconst, that's fine -- we think there is no tension between the concepts of immutablity and regularity.
Originally posted by @hsutter in https://github.com/isocpp/CppCoreGuidelines/issues/1917#issuecomment-1183458678
Before that, and especially in light of that, section "C. Concrete types" is fairly difficult to understand given all these nuances. It gives the strong impression that concrete types should be preferred (over hierarchies, which also gives the strong impression these are the only two "types" of types to consider, which may or may not be true, and the reader is left with questions like are immutable types regular? if not are they concrete? if not are they a third kind of type? if so, where do they fall in the preference spectrum?), and that concrete types are regular, and that concrete regular types are copyable (i.e. copy assignable) which implies that types with const members (i.e. immutable) are neither concrete nor regular. However according to the decision above, immutability and regularity are compatible, which means immutable types can be concrete (once we deal with C.12, see below) and we should improve the section to make this clear, namely by communicating the decision above: that immutability is compatible with regularity which is compatible with concreteness.
The other matter is the wording of "C.12: Don't make data members const or references". The wording "They are not useful, " has no rationale provided, does not meet the overall tone of the guidelines and reads like someone's personal opinion masquerading as fact. We know this statement to be provably false, both from the linked issue (which contains discussion of valuable uses for const data members), and more generally because the guidelines (through sections P.10 and other P-sections) extol the preference for immutable/const data.
The remaining part of the sentence may be true (they can make types more complicated to use by preventing copies) but does not seem a strong enough rationale, or at least needs to be reworded as to why that is incompatible with concrete types.
Preferably C.12 is removed as a rule and appears as a note alongside C.11 (similar to the note on move-only types) with an example (i.e. using vector<T> where T is non-copy-assignable)
which implies that types with const members (i.e. immutable) are neither concrete nor regular.
I think you are creating false dilemmas here.
As I said in the other thread: const members are an implementation detail. Regularity, immutablility and polymorphism are a interface properties. I can have an immutable type without const members and I can have a type with const members that still isn't immutable.
Same with conrete/abstract types and const members and (apparently) even regular types and const members.
Also, I can have a polymorphic type that is regular, as long as it is a leaf (i.e. final) type.
