On Mon, Jul 22, 2019 at 10:00 AM Karl Tomlinson <mozn...@karlt.net> wrote: > Google style requires pointers for parameters that may be mutated > by the callee, which provides that the potential mutation is > visible at the call site. Pointers to `const` types are > permitted, but recommended when "input is somehow treated > differently" [1], such as when a null value may be passed. > > Comments at function declarations should mention > "Whether any of the arguments can be a null pointer." [2]
I understand that there's value in adopting Google rules without modification in order to avoid having to discuss which parts to adopt and to avoid having to adapt tooling in accordance to the results of such discussion. However, what should we think of Google disagreeing with the C++ Core Guidelines, which can be expected to also have larger ecosystem value as a tooling target and that in some sense could be considered to come from higher C++ authority than Google's rules? On this particular topic, the Core Guidelines have: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-inout https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f60-prefer-t-over-t-when-no-argument-is-a-valid-option https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f23-use-a-not_nullt-to-indicate-that-null-is-not-a-valid-value (FWIW, I have relatively recently r+ed code that used non-const references to indicate non-nullable modifiable arguments on the grounds that it was endorsed by the Core Guidelines.) -- Henri Sivonen hsivo...@mozilla.com _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform