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:

(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