> On Aug 21, 2023, at 4:39 PM, Ryosuke Niwa <rn...@apple.com> wrote: > > >> On Aug 21, 2023, at 4:34 PM, Darin Adler <da...@apple.com> wrote: >> >> >>> On Aug 21, 2023, at 4:31 PM, Tim Horton via webkit-dev >>> <webkit-dev@lists.webkit.org> wrote: >>> >>>> One subtle thing is that even when a member variable is already Ref / >>>> RefPtr / CheckedRef / CheckedPtr, we must create another one in stack as >>>> seen here: >>>> https://commits.webkit.org/267108@main >>> >>> (I asked rniwa to send this mail because this patch surprised me, so I hope >>> now we can chat about it). >>> >>> The scope of this rule, and the … lack of elegance … at so many callsites >>> worries me a bit. If it’s possible to automate enforcement, that might help >>> with part of the problem, but it’s also just really not very pretty, and I >>> wonder if someone can come up with some clever alternative solution before >>> we go too far down this path (not me!). >>> >>> Alternatively, it’s possible other people OK with this syntax/requirement >>> and I should just get over it. What do you all think? >> >> I hope we can make this better by using a getter function that returns a >> CheckedPtr so instead of writing CheckedPtr { _page }, we would write page(). > > One drawback making a member function return CheckedPtr is that then code > like this: `page()->document()->foo()` would cause a ref churn. > > Maybe we don’t care about such ref churns?
How can we tell! > But then a simpler rule to deploy will be that every function must return > CheckedRef/CheckedPtr/Ref/RefPtr. +1 to that rule instead of the one in Wenson’s patch. > Alternatively, we could add a new member function which returns CheckedPtr > like `pageChecked()`. Would rather Darin’s plan. I don’t want to have to think about CheckedPtr every 5 seconds. > - R. Niwa >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
