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