tl;dr: There's a reason it's called "mangling"... On Mon, Aug 15, 2016 at 8:45 AM, Jim Blandy <jbla...@mozilla.com> wrote:
> 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
