#1191 replace member variable with data member

[eisenwave]

This PR implements #1191.

The colloquial term "member variable" is replaced with either:

• the C++ standardese term "data member"
• just "reference member", in the case of "reference member variable", a wording choice that is usually made in the C++ standard

It would be even less ambiguous to say "static data member" or "non-static data member", but this is very verbose and the reader can contextually understand whether non-static members are referred to. For example, when we write:

If a destructor is modifying a data member

This almost certainly doesn't refer to static data members, because it is impossible to initialize them in the constructor (unless lifetimes are managed explicitly).

While many C++ developers understand what a "member variable" is, it:

• can't be found anywhere in the C++ standard, making it more or less colloquial
• causes needless inconsistency with the term "data member", which is also used in this document
• has already sparked discussions such as #2078

[BenjamenMeyer]

The referenced discussion (#2078) doesn't seem to be much of a discussion with many commentators - it's three people, one of which asked the question and two of which (myself included) provided responses; both of which are more or less in agreement.

I'm not sure the request here really clarifies much if anything. When referencing classes memeber variable is probably more clear than data member in most circumstances. If anything the C++ standard should be updated to reflect the community.

FWIW - my :-1: is not so much opposition to the change itself, but the reasoning behind the change as the term member variable has a long history within the C and C++ communities.

[eisenwave]

I'm not sure the request here really clarifies much if anything. When referencing classes memeber variable is probably more clear than data member in most circumstances. If anything the C++ standard should be updated to reflect the community.

That's just your personal opinion. At the end of the day, cppreference, most StackOverflow questions, the C++ standard, most C++ books, etc. all use the term "data member". It is the correct term, whether you personally prefer it or not.

Whether the guidelines should be using data member or member variable is one question, another one is: should they be using the same term consistently in the whole document? The answer is obviously yes, and this PR adds that consistency. If you dislike the use of the term data member and want it changed to member variable, why don't you just make another PR that implements that throughout the document? For now, let's just be consistent.

[jvillemure]

Whatever decision we take, I think it is important to not use the word "variable" in the term we use to describe a non syatic data member. The term variable has already a meaning defined in the standard. Briefly, it is the name of an object or reference. But a non static data member declaration does not define an object. The distinction is important because most guidelines that would apply to objects or variables do not apply to non static data members and vice versa. In particular, regarding the use of const qualifier in the declarations: non static data members should never be declared const, but variables/objects declarations may favor the const qualifier depending on circumstances.

[iglesias]

The referenced discussion (https://github.com/isocpp/CppCoreGuidelines/issues/2078) suggests using non-static data member, whereas this change only renamed to data member.

[eisenwave]

The referenced discussion (#2078) suggests using non-static data member, whereas this change only renamed to data member.

That's a separate issue and a shortcoming of the original text. You would also need to disambiguate between

• static member variables
• non-static member variables

but this wasn't done because people sort of assume that "data member" or "member variable" refer to non-static, unless otherwise stated. I personally think it's fine to keep it this way as well. I'd be equally fine disambiguating it everywhere.

[hsutter]

Editors call: Thanks!