search

cplusplus / draft

C++ standards drafts
http://www.open-std.org/jtc1/sc22/wg21/
5.66k stars 749 forks source link

How to specify small nested classes: struct/class, private members #5323

Open tkoeppe opened 2 years ago

tkoeppe commented 2 years ago

We have a number of small, nested classes, mainly in the ranges library, which we currently variably specify with class and struct (e.g. outer-iterator, value_type). It might be helpful to pick one class key for all those cases.

A related question is how we order exposition-only members: previously, they used to appear at the end of the class defintion, but the ranges additions have started placing them at the beginning. We should discuss whether we want to mandate any particular style, or if there's value in allowing discretion.

Finally, this is related to the discussion of how to style exposition-only members (#4702).

tkoeppe commented 2 years ago

@jwakely, @CaseyCarter: LWG perspectives welcome!

tkoeppe commented 2 years ago

Tentatively, what would the rule for using struct be?

CaseyCarter commented 2 years ago

There are a ton of structs in Ranges, which I think is a consequence of the fact that Eric Niebler and I both prefer struct to class in our personal styles, and not the result of any explicit particular style choice on the part of LEWG or LWG. We wrote struct because that's what the implementations said, and nobody ever thought it important enough to ask me to change it.

I think Library generally uses the rule that structs have no private data members whereas classes have at least one and maintain invariants, but I wouldn't be surprised if Ranges wasn't the only violator of this rule.

jensmaurer commented 2 years ago

"No private members" is certainly a good first step. For purposes of the standard, some classes don't have any visible members, but they are containers or so and thus must have data members; they're just not shown. Those should be "class" as well.

tkoeppe commented 1 year ago

Editorial meeting opinion: This is not overly important, but we can certainly create and write down a rule. Based on the above, it should be something like "If it has invariants, it's a class, otherwise a struct".

tkoeppe commented 1 year ago

Added a wiki entry that recomends the above rule. No further action at this point, though cleanup PRs are welcome.