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
