Re: Coding style: brace initialization syntax

[bpostelnicu]

On Wednesday, June 6, 2018 at 5:21:05 AM UTC+3, gsqu...@mozilla.com wrote:
> On Wednesday, June 6, 2018 at 5:35:59 AM UTC+10, Boris Zbarsky wrote:
> > On 6/5/18 3:10 PM, Emilio Cobos Álvarez wrote:
> > > I personally would prefer one space at each side when using braces:
> > > 
> > >   , mFoo { 0 }
> > 
> > I think the reason people tend to think of this as not wanting spaces is 
> > that they are thinking of it as a constructor call.  The parentheses 
> > syntax for initializer lists helps think of things that way, of course.
> > [...]
> > -Boris
> 
> I also prefer `m{ 0 }`.
> 
> `m(0)` (direct initialization) and `m{ 0 }` (list initialization) are really 
> different operations, and may in fact call different constructors -- E.g., 
> the latter will prefer constructors that take an std::initializer_list.
> So I think it is important to emphasize the difference, especially for 
> reviewers to be able to pick on that difference.
> 
> g.

I completely agree with your point regarding the {} list initialize, and also 
the rest of opinions posted here. 
If what Eric wrote is the common ground here, I will be more than happy to 
update the the coding style doc. 
I think we’ve started to use “{ }” list initialiser on a mass scale since it 
was easier to implement the auto-fix for bug 525063.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Karl Tomlinson]

On Fri, 13 Apr 2018 10:22:06 -0400, Boris Zbarsky wrote:

> On 4/13/18 9:37 AM, Emilio Cobos Álvarez wrote:
>> Would people agree to use:
>>
>>   , mIsRootDefined { false }
>>
>> Instead of:
>>
>>   , mIsRootDefined{ false }
>
> So my take is that we should not use braced initializer syntax in
> constructor initializer lists.  The reason for that is that it
> makes it much harder to scan for where the constructor body
> starts.  Doubly so when ifdefs in the initializer list are
> involved.  Triply so when someone writes it as:
>
>   explicit TTextAttr()
> , mIsRootDefined
>   {
> false
>   }
> #ifdef SOMETHING
> #endif
>   {
>   }
>
> which is what clang-format did in some of the cases in the patch
> for bug 525063.
>
> In particular, I think this should have just used:
>
>   , mIsRootDefined(false)

One advantage of list-initialization over direct initialization is
that narrowing conversions are prohibited in list-initialization.
This is particularly useful in member initializer lists, where the
types are not readily visible (which is another good reason for
default member initialization).

I guess that doesn't matter for bool initializers, but consistency
...

Below, D will compile, but L will not.

struct D
{
  int i;
  D() : i(3.14) {}
};

struct L
{
  int i;
  L() : i{ 3.14 } {}
};

One advantage of lack of space between identifier and
brace-init-list is that it is visibly different from the space
before the constructor body.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[gsquelart]

On Wednesday, June 6, 2018 at 5:35:59 AM UTC+10, Boris Zbarsky wrote:
> On 6/5/18 3:10 PM, Emilio Cobos Álvarez wrote:
> > I personally would prefer one space at each side when using braces:
> > 
> >   , mFoo { 0 }
> 
> I think the reason people tend to think of this as not wanting spaces is 
> that they are thinking of it as a constructor call.  The parentheses 
> syntax for initializer lists helps think of things that way, of course.
> [...]
> -Boris

I also prefer `m{ 0 }`.

`m(0)` (direct initialization) and `m{ 0 }` (list initialization) are really 
different operations, and may in fact call different constructors -- E.g., the 
latter will prefer constructors that take an std::initializer_list.
So I think it is important to emphasize the difference, especially for 
reviewers to be able to pick on that difference.

g.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Boris Zbarsky]

On 6/5/18 3:10 PM, Emilio Cobos Álvarez wrote:

I personally would prefer one space at each side when using braces:

  , mFoo { 0 }


I think the reason people tend to think of this as not wanting spaces is 
that they are thinking of it as a constructor call.  The parentheses 
syntax for initializer lists helps think of things that way, of course.


Though I really find no-spaces-around-braces harder to read, not only in 
constructors but in general initializer lists. For example, I find:


   return { Foo::Bar, bar, baz };

easier to read than:

   return {Foo::Bar, bar, baz};


Right, whereas this one feels more like a struct literal of some sort, 
where you do want the spaces delimiting things...


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Emilio Cobos Álvarez]

On 06/05/2018 06:48 PM, Eric Rahm wrote:

Reading back through I think the consensus, at least for initializer lists
was:

1. Prefer parenthesis, ie:
, mBool(true)
2. If using braces, maintain the same spacing you would use with
parenthesis, ie:
, mStructWithoutCtor{42}

1. was pragmatic as this is what we already do, 2. was for consistency with
1.


I personally would prefer one space at each side when using braces:

 , mFoo { 0 }

But people seemed to think that for consistency we should use no spaces 
with braces as well... So if more people agree with that, oh well :)


Though I really find no-spaces-around-braces harder to read, not only in 
constructors but in general initializer lists. For example, I find:


  return { Foo::Bar, bar, baz };

easier to read than:

  return {Foo::Bar, bar, baz};

(and also more consistent with what you write in Javascript or Rust).

But nor sure if this discussion would expand to those cases.

 -- Emilio



To answer Bogdan's question, it looks like we prefer [1], although it would
be nice to see that codified in our style doc.

jya, you make some interesting points, but we should keep the scope of this
discussion focused. You might want to raise them in separate threads --
"Should we recommend initialization at member declaration", "Should we
recommend where a ctor should is defined", etc.

-e


On Tue, Jun 5, 2018 at 5:50 AM, Jean-Yves Avenard 
wrote:





On 5 Jun 2018, at 12:54 pm, bposteln...@mozilla.com wrote:

I would like to resurrect this thread since it would help us a lot for

bug 1453795 to come up to a consensus on when to use bracelets and when to
use parenthesis. Also I must point out a thing here, that was also
mentioned here earlier, that there are situations where we cannot use
parenthesis. This is when we want to initialize a structure that doesn't
have a ctor, like:

[1]
struct str {
  int a;
  int b;
};

class Str {
  str s;
  int a;
public:
  Str() : s{0}, a(0) {}
};

Also it would help a lot if we would establish how many, spaces should

be between the parenthesis or the bracelets, like how do we prefer [1] or
[2]


[2]
class Str {
  str s;
  int a;
public:
  Str() : s{ 0 }, a( 0 ) {}
};

I don't have a personal preference here, but right now there are several

places in our code that combine spaces between parenthesis/bracelets with
no spaces.

The current coding style: https://developer.mozilla.org/
en-US/docs/Mozilla/Developer_guide/Coding_Style states to not use space.

There’s no case where a parenthesis should be followed by a space.

Many things wrong here:
First the bracket { should be on a new line :

class/struct str
{
…
}

Initialization are to be on multiple-lines.

clang-format would have made it:
   class Str
   {
 str s;
 int a;

   public:
 Str()
   : s{ 0 }
   , a(0)
 {
 }
   };

IMHO, should be going for C++11 initializer, it’s much clearer, and avoid
duplicated code when you need multiple constructors.
What is str? I assume not a plain object, so it should have its own
initializer.

so it all becomes:
   class Str
   {
 str s;
 int a = 0;

   public:
 Str() {}
   };

or:
   class Str
   {
 str s;
 int a = 0;

   public:
 Str() = default;
   };

(and I prefer constructors to be defined at the start of the class
definition)

My $0.02
___
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


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Eric Rahm]

Reading back through I think the consensus, at least for initializer lists
was:

   1. Prefer parenthesis, ie:
   , mBool(true)
   2. If using braces, maintain the same spacing you would use with
   parenthesis, ie:
   , mStructWithoutCtor{42}

1. was pragmatic as this is what we already do, 2. was for consistency with
1.

To answer Bogdan's question, it looks like we prefer [1], although it would
be nice to see that codified in our style doc.

jya, you make some interesting points, but we should keep the scope of this
discussion focused. You might want to raise them in separate threads --
"Should we recommend initialization at member declaration", "Should we
recommend where a ctor should is defined", etc.

-e


On Tue, Jun 5, 2018 at 5:50 AM, Jean-Yves Avenard 
wrote:

>
>
> > On 5 Jun 2018, at 12:54 pm, bposteln...@mozilla.com wrote:
> >
> > I would like to resurrect this thread since it would help us a lot for
> bug 1453795 to come up to a consensus on when to use bracelets and when to
> use parenthesis. Also I must point out a thing here, that was also
> mentioned here earlier, that there are situations where we cannot use
> parenthesis. This is when we want to initialize a structure that doesn't
> have a ctor, like:
> > [1]
> > struct str {
> >  int a;
> >  int b;
> > };
> >
> > class Str {
> >  str s;
> >  int a;
> > public:
> >  Str() : s{0}, a(0) {}
> > };
> >
> > Also it would help a lot if we would establish how many, spaces should
> be between the parenthesis or the bracelets, like how do we prefer [1] or
> [2]
> >
> > [2]
> > class Str {
> >  str s;
> >  int a;
> > public:
> >  Str() : s{ 0 }, a( 0 ) {}
> > };
> >
> > I don't have a personal preference here, but right now there are several
> places in our code that combine spaces between parenthesis/bracelets with
> no spaces.
>
> The current coding style: https://developer.mozilla.org/
> en-US/docs/Mozilla/Developer_guide/Coding_Style states to not use space.
>
> There’s no case where a parenthesis should be followed by a space.
>
> Many things wrong here:
> First the bracket { should be on a new line :
>
> class/struct str
> {
> …
> }
>
> Initialization are to be on multiple-lines.
>
> clang-format would have made it:
>   class Str
>   {
> str s;
> int a;
>
>   public:
> Str()
>   : s{ 0 }
>   , a(0)
> {
> }
>   };
>
> IMHO, should be going for C++11 initializer, it’s much clearer, and avoid
> duplicated code when you need multiple constructors.
> What is str? I assume not a plain object, so it should have its own
> initializer.
>
> so it all becomes:
>   class Str
>   {
> str s;
> int a = 0;
>
>   public:
> Str() {}
>   };
>
> or:
>   class Str
>   {
> str s;
> int a = 0;
>
>   public:
> Str() = default;
>   };
>
> (and I prefer constructors to be defined at the start of the class
> definition)
>
> My $0.02
> ___
> 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

Re: Coding style: brace initialization syntax

[Jean-Yves Avenard]

> On 5 Jun 2018, at 12:54 pm, bposteln...@mozilla.com wrote:
> 
> I would like to resurrect this thread since it would help us a lot for bug 
> 1453795 to come up to a consensus on when to use bracelets and when to use 
> parenthesis. Also I must point out a thing here, that was also mentioned here 
> earlier, that there are situations where we cannot use parenthesis. This is 
> when we want to initialize a structure that doesn't have a ctor, like:
> [1]
> struct str {
>  int a;
>  int b;
> };
> 
> class Str {
>  str s;
>  int a;
> public:
>  Str() : s{0}, a(0) {}
> };
> 
> Also it would help a lot if we would establish how many, spaces should be 
> between the parenthesis or the bracelets, like how do we prefer [1] or [2]
> 
> [2]
> class Str {
>  str s;
>  int a;
> public:
>  Str() : s{ 0 }, a( 0 ) {}
> };
> 
> I don't have a personal preference here, but right now there are several 
> places in our code that combine spaces between parenthesis/bracelets with no 
> spaces.

The current coding style: 
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style 
states to not use space.

There’s no case where a parenthesis should be followed by a space.

Many things wrong here:
First the bracket { should be on a new line :

class/struct str
{
…
}

Initialization are to be on multiple-lines.

clang-format would have made it:
  class Str
  {
str s;
int a;

  public:
Str()
  : s{ 0 }
  , a(0)
{
}
  };

IMHO, should be going for C++11 initializer, it’s much clearer, and avoid 
duplicated code when you need multiple constructors.
What is str? I assume not a plain object, so it should have its own initializer.

so it all becomes:
  class Str
  {
str s;
int a = 0;

  public:
Str() {}
  };

or:
  class Str
  {
str s;
int a = 0;

  public:
Str() = default;
  };

(and I prefer constructors to be defined at the start of the class definition)

My $0.02

smime.p7s
Description: S/MIME cryptographic signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[bpostelnicu]

I would like to resurrect this thread since it would help us a lot for bug 
1453795 to come up to a consensus on when to use bracelets and when to use 
parenthesis. Also I must point out a thing here, that was also mentioned here 
earlier, that there are situations where we cannot use parenthesis. This is 
when we want to initialize a structure that doesn't have a ctor, like:
[1]
struct str {
  int a;
  int b;
};

class Str {
  str s;
  int a;
public:
  Str() : s{0}, a(0) {}
};

Also it would help a lot if we would establish how many, spaces should be 
between the parenthesis or the bracelets, like how do we prefer [1] or [2]

[2]
class Str {
  str s;
  int a;
public:
  Str() : s{ 0 }, a( 0 ) {}
};

I don't have a personal preference here, but right now there are several places 
in our code that combine spaces between parenthesis/bracelets with no spaces.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Botond Ballo]

On Fri, Apr 13, 2018 at 11:06 AM, Emilio Cobos Álvarez  wrote:
>> If we are going to have brace-initialization intermixed with
>> list-initialization (i.e. parentheses) in our codebase, I think we
>> should prefer no space prior to the brace, for consistency.
>
> Hmm, consistency with parenthesis I guess, but not with other things that
> use braces, like conditionals or other kind of declarations (where we use a
> space after the paren, for example), or lambdas where we use `mutable {`,
> etc.

Braces are used for a variety of purposes in C++. I think it makes
more sense to adapt the style to the purpose, than to try to enforce a
common style across all kinds of brace uses. We already do this; for
example, some uses of braces go on their own line, and others don't.

In this case, I think it makes sense for braces used for
initialization to be consistent with parentheses used for
initialization.

> Also, I guess per that argument we should use `mIsRootDefined{false}`
> instead of `mIsRootDefined{ false }`.

+1. `mIsRootDefined{false}` is what I've been using in constructor initializers.

Cheers,
Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Kartikaya Gupta]

On Fri, Apr 13, 2018 at 11:06 AM, Emilio Cobos Álvarez  wrote:
> I'd be ok with that I guess, though it's more common each time? Also, is
> there any case where you could use braces but not parenthesis? (I'm not a
> C++ expert in this regard).

I think there are. In particular if you're initializing a struct by
members which doesn't have a constructor. For instance, when I
recently upgraded layers id from a uint64_t to a struct, I had to use
{} in initializer lists instead of () because I didn't add a
constructor to the struct. Here's a simple example:

struct Foo {
int x;
};

struct Bar {
Bar()
: mFoo(0)   // <-- this fails, but {} will work
{
}

Foo mFoo;
};
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Emilio Cobos Álvarez]

On 4/13/18 4:49 PM, Nathan Froyd wrote:

On Fri, Apr 13, 2018 at 9:37 AM, Emilio Cobos Álvarez  wrote:

Those changes I assume were generated with clang-format / clang-format-diff
using the "Mozilla" coding style, so I'd rather ask people to agree in
whether we prefer that style or other in order to change that if needed.

Would people agree to use:

  , mIsRootDefined { false }

Instead of:

  , mIsRootDefined{ false }

What's people's opinion on that? Would people be fine with a more general
"spaces around braces" rule? I can't think of a case right now where I
personally wouldn't prefer it.


If we are going to have brace-initialization intermixed with
list-initialization (i.e. parentheses) in our codebase, I think we
should prefer no space prior to the brace, for consistency. 


Hmm, consistency with parenthesis I guess, but not with other things 
that use braces, like conditionals or other kind of declarations (where 
we use a space after the paren, for example), or lambdas where we use 
`mutable {`, etc.


Also, I guess per that argument we should use `mIsRootDefined{false}` 
instead of `mIsRootDefined{ false }`.



If we are going to switch wholesale (which would be a big job!)... I'd
probably say "no space", just on "that's the way we've always done it"
grounds, but can be convinced otherwise.


Though this is a good point though, I've only found a couple of them 
with spaces:


  $ rg ' m[A-Z][A-Za-z]* \{ ' | wc -l 



  9

vs.

  $ rg ' m[A-Z][A-Za-z]*\{ ' | wc -l
  516

Though that could be an artifact of clang-format in the directories we 
run it.



I agree with bz on disallowing braces in constructor init lists.


I'd be ok with that I guess, though it's more common each time? Also, is 
there any case where you could use braces but not parenthesis? (I'm not 
a C++ expert in this regard).



Also, we should probably state that consistency is preferred (I assume we
generally agree on that), so in this case braces probably weren't even
needed, or everything should've switched to them.


Indeed.


Finally, while I'm here, regarding default member initialization, what's
preferred?

   uint32_t* mFoo = nullptr;

Or:

   uint32_t* mFoo { nullptr };


I lean towards the former here.  I think the former is more common in
the code I've seen, but apparently the latter is "preferred C++" or
something?


I think the former is ok, but wouldn't work for stuff like:

  Atomic mFoo = nullptr;

While:

Atomic mFoo { nullptr };

does work.

 -- Emilio
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Gabriele Svelto]

On 13/04/2018 16:49, Nathan Froyd wrote:
> I lean towards the former here.  I think the former is more common in
> the code I've seen, but apparently the latter is "preferred C++" or
> something?

Yes, let's have a solid rationale if we're doing sweeping changes of
this sort. Blindly following the "C++ flavor du jour" is going to lead
to a lot of unnecessary churn.

 Gabriele
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Nathan Froyd]

On Fri, Apr 13, 2018 at 9:37 AM, Emilio Cobos Álvarez  wrote:
> Those changes I assume were generated with clang-format / clang-format-diff
> using the "Mozilla" coding style, so I'd rather ask people to agree in
> whether we prefer that style or other in order to change that if needed.
>
> Would people agree to use:
>
>  , mIsRootDefined { false }
>
> Instead of:
>
>  , mIsRootDefined{ false }
>
> What's people's opinion on that? Would people be fine with a more general
> "spaces around braces" rule? I can't think of a case right now where I
> personally wouldn't prefer it.

If we are going to have brace-initialization intermixed with
list-initialization (i.e. parentheses) in our codebase, I think we
should prefer no space prior to the brace, for consistency.  If we are
going to switch wholesale (which would be a big job!)...I'd probably
say "no space", just on "that's the way we've always done it" grounds,
but can be convinced otherwise.

I agree with bz on disallowing braces in constructor init lists.

> Also, we should probably state that consistency is preferred (I assume we
> generally agree on that), so in this case braces probably weren't even
> needed, or everything should've switched to them.

Indeed.

> Finally, while I'm here, regarding default member initialization, what's
> preferred?
>
>   uint32_t* mFoo = nullptr;
>
> Or:
>
>   uint32_t* mFoo { nullptr };

I lean towards the former here.  I think the former is more common in
the code I've seen, but apparently the latter is "preferred C++" or
something?

-Nathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Boris Zbarsky]

On 4/13/18 9:40 AM, Alex Gaynor wrote:

I don't have an opinion on the style change itself, but I'm a very strong
+1 on just picking one and making sure clang-format enforces it.


We need to fix clang-format to not produce output like 
https://hg.mozilla.org/mozilla-central/diff/d7d2f08e051c/dom/bindings/BindingDeclarations.h 
before we talk about enforcing this sort of thing with clang-format


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Boris Zbarsky]

On 4/13/18 9:37 AM, Emilio Cobos Álvarez wrote:

Would people agree to use:

  , mIsRootDefined { false }

Instead of:

  , mIsRootDefined{ false }


So my take is that we should not use braced initializer syntax in 
constructor initializer lists.  The reason for that is that it makes it 
much harder to scan for where the constructor body starts.  Doubly so 
when ifdefs in the initializer list are involved.  Triply so when 
someone writes it as:


  explicit TTextAttr()
, mIsRootDefined
  {
false
  }
#ifdef SOMETHING
#endif
  {
  }

which is what clang-format did in some of the cases in the patch for bug 
525063.


In particular, I think this should have just used:

  , mIsRootDefined(false)

I don't have a strong opinion about the one space when we do use the 
braced initializer syntax.  But we should make sure we don't end up with 
the above monstrosity where it looks like the ctor body.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: brace initialization syntax

[Alex Gaynor]

I don't have an opinion on the style change itself, but I'm a very strong
+1 on just picking one and making sure clang-format enforces it.

Alex

On Fri, Apr 13, 2018 at 9:37 AM, Emilio Cobos Álvarez 
wrote:

> Sorry, I know, coding style thread... But it's Friday and this is somewhat
> related to the previous thread.
>
> Bug 525063 added a lot of lines like:
>
> explicit TTextAttr(bool aGetRootValue)
>   : mGetRootValue(aGetRootValue)
>   , mIsDefined{ false }
>   , mIsRootDefined{ false }
> {
> }
>
> I think I find them hard to read and ugly.
>
> Those changes I assume were generated with clang-format /
> clang-format-diff using the "Mozilla" coding style, so I'd rather ask
> people to agree in whether we prefer that style or other in order to change
> that if needed.
>
> Would people agree to use:
>
>  , mIsRootDefined { false }
>
> Instead of:
>
>  , mIsRootDefined{ false }
>
> And:
>
>  , mFoo { }
>
> Instead of:
>
>  , mFoo{}
>
> ?
>
> I assume the same would be for variables, I find:
>
>   AutoRestore restore { mFoo };
>
> easier to read than:
>
>   AutoRestore restore{ mFoo };
>
> What's people's opinion on that? Would people be fine with a more general
> "spaces around braces" rule? I can't think of a case right now where I
> personally wouldn't prefer it.
>
> Also, we should probably state that consistency is preferred (I assume we
> generally agree on that), so in this case braces probably weren't even
> needed, or everything should've switched to them.
>
> Finally, while I'm here, regarding default member initialization, what's
> preferred?
>
>   uint32_t* mFoo = nullptr;
>
> Or:
>
>   uint32_t* mFoo { nullptr };
>
> I'm ambivalent, but brace syntax should cover more cases IIUC (that is,
> there are things that you can write with braces that you couldn't with
> equals I _think_).
>
> Should we state a preference? Or just say that both are allowed but
> consistency is better?
>
>  -- Emilio
> ___
> 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