I don't know. I didn't define the standard. But IMO private is best, as not to compromise the class contents, if anything.
I have made private-only classes and declared friend classes to make sure only a specific class can use the object. Maybe not THE best idea, but it works, at least when there's no complications with private/public members and functions.
Of course, I have lots of classes WITH public interface. And there's a pretty "public" before those functions/variables too.
If backward compatibility with C had not been a consideration, we would probably have a language with only ONE class keyword, not two.
I think you are missing the point of the very rule you use. Let's take a look at Stroustrup's glossary on struct: "class with members public by default. Most often used for data structures without member functions or class invariants, as in C-style programming."I don't know. I didn't define the standard. But IMO private is best, as not to compromise the class contents, if anything.
Let's take a look at what the Dictionary of Algorithms and Data Structures has to say about data structures and abstract data types:
abstract data type: A set of data values and associated operations that are precisely specified independent of any particular implementation.
data structure: An organization of information, usually in memory, for better algorithm efficiency, such as queue, stack, linked list, heap, dictionary, and tree, or conceptual unity, such as the name and address of a person.
Since there are no associated operations specified in a data structure, it makes sense that some mechanism for specifying a data structure not restrict access to the values of that data structure. Consequently, struct, which has public visibility by default, is a good fit.
On the other hand, a mechanism for implementing an abstract data type (it will no longer be abstract I suppose, haha) may wish to have restrictions placed on accessing the data values since the associated operations are already "precisely specified". class is a better fit than struct because of its default private visibility.
As such, I think that the advice to "don't go around choosing just because of the default visibility" has some truth in it, but to say that "using structs/classes depending on the default access is silly" is silly.
I use class for classes and add/change public, private and protected appropriately.
If I simply need a big data structure, with only members to store data packed together, I use struct.
It does not matter what the default visibility is. I don't choose struct if I want to add functions to a class. I don't choose class if I ONLY want member variables (OK, so maybe I do sometimes, if I think I might need to expand the functionality from just member variables to add functions and operators).