Aaron Ballman

All of this library code is part of the implementation, so I think all of the identifiers (aside from parts of the public API other than parameter names) should be...

> > All of this library code is part of the implementation, so I think all of the identifiers (aside from parts of the public API other than parameter names)...

My suggestion is to use `__` prefix for all names that are not exposed to the user as part of the public API. e.g., go with regular identifiers for classes,...

STL libraries are not required to do this as a matter of specification, but they do it as a matter of Quality of Implementation because of just how often user-defined...

I think this makes sense -- using clang-tidy and integrating that into the CI pipeline will help keep the headers hygienic for macros. Given that it will be a custom...

> Do internal macros also need to follow the reserved naming requirements? If yes, how can we be sure it does not interfere with other libraries? Yes; praying might do...

> How do you define the "implementation" Colloquially, I define it as "everything that ships with the compiler or is necessary to make hello world work." e.g., everything in clang\lib\Headers...

> * contrary to the LLVM coding guide, forbid the CamelStyle identifiers within functions in the API headers, and use lower-case always. Most macro names are all-caps like VL, so...

> As I mentioned, I don't think we can have a solution. We can only have a mitigation. Using lower-case will reduce the chance of conflict significantly. Correct, there are...

> I understand but if security is a concern, maybe making this disabled by default is a better option even if it is not as user-friendly, I am not a...