On Mon, Aug 15, 2016 at 10:30 PM, Nathan Froyd <nfr...@mozilla.com> wrote: > On Mon, Aug 15, 2016 at 9:56 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: >> Relatedly, on the topic of MFBT Range and GSL, under the subject "C++ >> Core Guidelines" Jim Blandy <jbla...@mozilla.com> wrote: >>> 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? > > Keeping the Gecko naming scheme avoids unwanted name conflicts versus > the standard library,
Isn't what what the mozilla:: and std:: namespaces are supposed to be for? I'm having a déjà vu from XML. :-) > and makes it a bit clearer in code where > prefixes are not present that something Gecko-ish is being used. The > latter is helpful for things that are named similarly to the standard, > but differ dramatically (mozilla::Vector, mozilla::IsPod). OK, this makes sense when things in MFBT are not, in fact, polyfills. >> 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. > > I don't follow the argument here for Rust names. If the C++ recreation of the Rust API used snake_case method names, it would be copy-paste-friendlier than the C++ recreation of the Rust API using Gecko C++-style method names. When creating the C++ API in the first place, you could just copy and paste the names. When creating the documentation for it, you could copy and paste the Rust docs without altering names when docs refer to other methods. When using the API and taking an example use from Rust, after copying and pasting you could mostly do things that are unavoidable like replacing '.' with '->' and replacing 'let (foo, bar) =' with 'Tie(foo, bar) ='. When the C++ recreation of the Rust API uses Gecko C++-style method names, for all of these, you'll have to do a (likely manual in practice even though algorithmic in principle) pass over the code and capitalize the first letter of each method, capitalize each letter following an underscore and then removing the underscores, which is not particularly productive. > I think it's > reasonable that if one needs to call FFI functions in Rust directly, > then we should use whatever names the Rust library chose for its FFI > interface. That policy is no different than what we have today for > third-party libraries. But if one is going to write wrappers around > those FFI functions (resp. third-party libraries), then it seems > equally reasonable that those wrappers should follow Gecko > conventions, and not the conventions of whatever code they are > wrapping. Again, this is no different than what we have today for > third-party libraries. OK. There seems to be consensus that this is the way to go. > For GSL polyfills, I think that we should continue to follow the MFBT > conventions set thus far and use Gecko style for naming. OK. > But that is > partly skepticism about how much in GSL will actually get used Considering how useful the concept of slices as a language-supported construct is in Rust, I'd hope that if we had a gsl::span or mozilla::Span, we'd use it about as frequently as slices are used in Rust and stopped passing pointer-and-length as separate arguments in newly-written C++. (As for gsl::span/mozilla::Span vs. mozilla::Range, since Rust slices use pointer-and-length, which decomposes to pointer and length in FFI, it seem beneficial for the C++ counterpart to also have pointer and length internally so that decomposing it to pointer and length for FFI and recreating a slice from raw parts, or vice versa, doesn't involve any back-and-forth arithmetic.) -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
