I object. I don’t find using { *this } in a header disorienting at all. I
think it’s better than adding many duplicate lines in each constructor and
risking forgetting one. I think if we were to remove all the
m_attributeOwnerProxy initializers in WebKit it would add lots of duplication
with little benefit. If it were a class with a default constructor we would
have a high risk of forgetting a constructor somewhere.
> On Mar 20, 2019, at 9:22 AM, Simon Fraser <simon.fra...@apple.com> wrote:
>
>> On Mar 14, 2019, at 1:06 PM, Filip Pizlo <fpi...@apple.com> wrote:
>>
>> I like to draw this distinction: is the initializer a constant?
>>
>> It’s not a constant if it relies on arguments to the constructor. “This” is
>> an argument to the constructor.
>>
>> It’s also not a constant if it involves reading the heap.
>>
>> So, like you, I would want to see this code done in the constructor. But I’m
>> not sure that my general rule is the same as everyone’s.
>
> This seems like a reasonable proposal to me: only use initializers when their
> input is constant data.
>
> Any objections?
>
> Simon
>
>>
>> -Filip
>>
>>> On Mar 14, 2019, at 12:59 PM, Simon Fraser <simon.fra...@apple.com> wrote:
>>>
>>> I've seen some code recently that initializes non-POD members via
>>> initializers. For example, SVGAElement has:
>>>
>>> AttributeOwnerProxy m_attributeOwnerProxy { *this };
>>>
>>> I find this a little disorientating, and would normally expect to see this
>>> in the constructor as m_attributeOwnerProxy(*this), as it makes it easier
>>> to find places to set breakpoints, and the ordering of initialization is
>>> easier to see.
>>>
>>> Are people OK with this pattern, or should we discourage it via the style
>>> guidelines (and style checker)?
>>>
>>> Simon
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
