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

Reply via email to