[PATCH] D52771: [clang-tidy] Non-private member variables in classes (MISRA, CppCoreGuidelines, HICPP)

[Aaron Ballman via Phabricator via cfe-commits]

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