[webkit-dev] Smart Pointers Usage Guidelines

[Ryosuke Niwa]

> 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? But then a simpler rule to deploy will be that every function must return CheckedRef/CheckedPtr/Ref/RefPtr.

Alternatively, we could add a new member function which returns CheckedPtr like `pageChecked()`.

- R. Niwa

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