[webkit-dev] Smart Pointers Usage Guidelines

[Tim Horton]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20230821/bd515e4f/attachment.htm>