We've already established that Rust code in m-c will use the Rust coding style, so we'll have snake_case methods and functions in Rust code in m-c. Also, Rust code that exposes an FFI interface typically does so with snake_case functions, which look natural both for Rust and for C as C style is influenced by the C standard library.
When a Rust library provides a C++ interface, the C++ interface is built on top of the C/FFI interface. Per above, the Rust and C layers use snake_case for methods/functions. As it happens, the C++ standard library also uses snake_case, so for a C++ interface to a Rust library outside of the Gecko context, it's not unnatural to use snake_case methods on the C++ layer, too. Like this: https://github.com/hsivonen/encoding_rs/blob/master/include/encoding_rs_cpp.h Since Gecko has does not use C++ standard-library strings and, at least currently, does not use GSL, a slightly different C++ wrapper is called for in the Gecko case. But should such a wrapper just use XPCOM nsACString and MFBT Range or should it also change the names of the methods to follow Gecko case rules? Relatedly, on the topic of MFBT Range and GSL, under the subject "C++ Core Guidelines" Jim Blandy <jbla...@mozilla.com> wrote: > Given GSL's pedigree, I was assuming that we'd bring it in-tree and switch > out MFBT facilities with the corresponding GSL things as they became > available. > > One of the main roles of MFBT is to provide polyfills for features > standardized in C++ that we can't use yet for toolchain reasons (remember > MOZ_OVERRIDE?); MFBT features get removed as we replace them with the > corresponding std thing. I'd have expected a polyfill that expects to be swapped out to use the naming of whatever it's polyfill for, except maybe for the namespace. Since MFBT has mozilla::UniquePtr instead of mozilla::unique_ptr, I had understood mozilla::UniquePtr as a long-term Gecko-specific implementation of the unique pointer concept as opposed to something that's expected to be replaced with std::unique_ptr as soon as feasible. Are we getting value out of going against the naming convention of the C++ standard library in order to enforce a Mozilla-specific naming style? I suggest that we start allowing snake_case C++ in m-c so that C++ wrappers for the C interfaces to Rust code can be named with mere copy-paste of the Rust method names and so that we don't need to change naming style of GSL stuff regardless of whether what's in the tree is a Mozilla polyfill for GSL, a third-party polyfill (for legacy compilers) of GSL or GSL itself. Of course, we won't change all existing code to snake_case at the same time, and the mix of Mozilla C++ case and snake_case would be somewhat aesthetically offensive. But does maintaining a house style that differs from e.g. the standard library of C++ itself provide us more value that more direct copypasteability would? (FWIW, as precedent, in the HTML parser, the names of methods that are translated from Java use Java naming conventions. Since that code goes through a translator anyway, as opposed to be manual copypasta, I offered to make the translator change the method naming to Mozilla C++ style but was told not to bother.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
