> > 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. >
Has anyone suggested mangling C++ bindings for Rust definitions into Mozilla C++ style, making them different from the Rust names? I'm opposed! :) In the most general case, cross-language adapters must mangle the names they deal with. For example, XPIDL has to affix something to IDL attribute names when naming the C++ accessors, and "Get" and "Set" prefixes aren't worse than anything else. And maybe the languages just have different identifier syntaxes, so mangling is necessary simply to produce well-formed code. But when an unmangled conversion is possible, that seems clearly preferable. We're using Cheddar to produce C headers for our Rust mp4parse crate; as far as I can see, Cheddar doesn't mangle Rust names. The Mozilla C++ style applies only to identifiers defined in Mozilla's C++ code base, not things that we merely use that are defined elsewhere. When we use upstream code, we use its definitions in the form they're offered. I think Rust code should be treated similarly to "upstream" code in that sense, and the C++ should use the Rust names unchanged. It's true that the benefit from a convention increases the more consistently it's applied, but as long as we want to use upstream code bases, we must work in a multi-style world, so universal conformance is just never going to happen. In that light, the C++ standard and GSL are just two more cases of an upstream project not matching Mozilla style. You don't quite spell it out out, but I feel like you're hoping to argue that the C and C++ standard libraries' use of snake_case suggests that it's somehow acceptable, or ought to be acceptable, for Mozilla C++ definitions too. But these are mostly arbitrary decisions, and our well-established arbitrary decision is that that's not acceptable. On Mon, Aug 15, 2016 at 6:56 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > 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
