I agree with Jim that the introduction of Rust code doesn't fundamentally
alter the dynamic of our style conventions. We're not going to get
consistency with all upstream projects and bound languages no matter what
convention we pick, and changing mozilla style would be hugely disruptive.
Regarding which style to pick for the boundary:
Rust already uses CamelCase types. In Stylo, we're using CamelCase
functions for our FFI bindings, along with a Gecko_ or Servo_ prefix to
indicate on which side of the boundary the function is defined. This makes
sense for a variety of reasons:
* The binding generator we have goes from .h => .rs, not the other way
around. So the code we hand-write is mostly-idiomatic code, while the
generated code is not (which is preferable to the alternatively).
* Invoking C++ functions from rust is already clunky because you have to
use unsafe { }, so it doesn't hurt much for the function naming to be
non-idiomatic there.
* Rust/Servo have good tooling already (tidy) to enforce stylistic
consistency, with explicit granular opt-outs. This means that non-idiomatic
style is less likely to unintentionally spread in Rust than in C++.
* We can represent most C++ types in Rust but not vice-versa. This (along
with the need for custom linkage) means that Rust APIs already need a lot
of special stuff to be usable from C++, so the naming convention is not an
onerous requirement.
* Similar to the above, we end up using lots of non-primitive C++ types as
non-opaque in Rust, but non-primitive Rust types are pretty much always
opaque in C++. This means that the C++ style convention has more momentum
at the boundary.
http://searchfox.org/mozilla-central/source/layout/style/ServoBindings.h
https://github.com/servo/servo/blob/master/ports/geckolib/gecko_bindings/bindings.rs
https://github.com/servo/servo/blob/master/ports/geckolib/wrapper.rs
https://github.com/servo/servo/blob/master/ports/geckolib/glue.rs
bholley
On Mon, Aug 15, 2016 at 8:46 AM, Jim Blandy <jbla...@mozilla.com> wrote:
> 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
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
