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 inf
>
> 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 po
tl;dr: There's a reason it's called "mangling"...
On Mon, Aug 15, 2016 at 8:45 AM, Jim Blandy 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
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.
Regardin
On Mon, Aug 15, 2016 at 6:45 PM, Jim Blandy wrote:
> 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
On Mon, Aug 15, 2016 at 11:53 AM, Henri Sivonen
wrote:
> On Mon, Aug 15, 2016 at 6:45 PM, Jim Blandy wrote:
> > 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 identi
On Mon, Aug 15, 2016 at 9:56 AM, Henri Sivonen wrote:
> Relatedly, on the topic of MFBT Range and GSL, under the subject "C++
> Core Guidelines" Jim Blandy 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 reaso
On Aug 15, 2016 21:59, "Bobby Holley" wrote:
>
> On Mon, Aug 15, 2016 at 11:53 AM, Henri Sivonen
wrote:
>>
>> On Mon, Aug 15, 2016 at 6:45 PM, Jim Blandy wrote:
>> > 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.
On Mon, Aug 15, 2016 at 11:59 AM, Bobby Holley
wrote:
> On Mon, Aug 15, 2016 at 11:53 AM, Henri Sivonen
> wrote:
>
>> What I'm asking is:
>>
>> When I take encoding_rs_cpp.h and adapt it to XPCOM/MFBT types for use
>> in Gecko, should this be
>> Encoding::for_label(const nsACString& label) // ch
On Mon, Aug 15, 2016 at 10:30 PM, Nathan Froyd wrote:
> On Mon, Aug 15, 2016 at 9:56 AM, Henri Sivonen wrote:
>> Relatedly, on the topic of MFBT Range and GSL, under the subject "C++
>> Core Guidelines" Jim Blandy wrote:
>>> One of the main roles of MFBT is to provide polyfills for features
>>>
On Tue, Aug 16, 2016 at 2:19 PM, Henri Sivonen wrote:
>> For GSL polyfills, I think that we should continue to follow the MFBT
>> conventions set thus far and use Gecko style for naming.
>
> OK.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1295611 to
request mozilla::Span in MFBT.
--
He
11 matches
Mail list logo
