aaron.ballman added a comment. In https://reviews.llvm.org/D52771#1256511, @JonasToth wrote:
> In https://reviews.llvm.org/D52771#1256432, @aaron.ballman wrote: > > > I can't help but notice how badly C.133 and C.9 interact with C.131 and I'm > > worried we will wind up with clang-tidy checks that leave the user in an > > impossible situation where they need to make data members private and > > provide trivial accessors for them. Do you have thoughts on how to avoid > > that? The C++ Core Guidelines seem silent on the matter -- this might be > > worth raising with the authors. > > > I have an idea to avoid trivial set/get methods: Flag public data if it is > modified internally. This could serve as a heuristic for pre/postconditions > on that variable. > In general one could resolve all data-dependencies inside the class and > figure out if a private variable would need to change if a public variable > got changed. But that is way more complex! Hmm, I don't know that it would help with code like this: class Base { int f; // Suggested by C.133/C.9 protected: // int f; // Disallowed by C.133 int getF() const { return f; } // Suggested by C.133, disallowed by C.131 void setF(int NewF) { f = NewF; } // Suggested by C.133, disallowed by C.131 }; > Still worth asking the authors. Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D52771 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
