On Aug 21, 2023, at 4:39 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
On Aug 21, 2023, at 4:34 PM, Darin Adler <darin@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