JonasToth added a comment. 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! 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
