Re: [webkit-dev] Style guideline on initializing non-POD types via member initialization

2019-03-21 Thread Alex Christensen
A more specific example of why I object is that I want to do things like add a pointer to the thread an object was created on if ASSERT_DISABLED is false so I can assert if things are done on invalid threads. If I do this in a class like RefCounted, this rule would make me add a guarded

Re: [webkit-dev] Style guideline on initializing non-POD types via member initialization

2019-03-21 Thread Alex Christensen
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

Re: [webkit-dev] Style guideline on initializing non-POD types via member initialization

2019-03-20 Thread Simon Fraser
> On Mar 14, 2019, at 1:06 PM, Filip Pizlo 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

Re: [webkit-dev] Style guideline on initializing non-POD types via member initialization

2019-03-14 Thread Filip Pizlo
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