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, 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). Removing the polyfills to use something more standardized requires only sed/perl-style renaming (mostly). Manual effort to adjust includes would be necessary whether we chose Gecko style or standard library 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. I don't follow the argument here for Rust names. 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. For GSL polyfills, I think that we should continue to follow the MFBT conventions set thus far and use Gecko style for naming. But that is partly skepticism about how much in GSL will actually get used and/or how quickly GSL would get standardized and provided by our compiler vendors. -Nathan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
