After some Slack chat, I’d like to propose
`protected(x)`
as the canonical way to make either a RefPtr/Ref or CheckedPtr/CheckedRef
temporary.
Rationale: It’s a bit more readable than RefPtr { x } / Ref { x } / CheckedPtr
{ x } / CheckedRef { x }, and it’s much more adoptable by automated tooling. If
we ask automated tooling to decide the right formulation, it has to go read a
bunch of headers and make a bunch of dependent decisions, which can be
expensive and error-prone. If we provide a single function, there’s only one
thing to do, and you blast it everywhere.
Thanks,
Geoff
> On Jan 13, 2026, at 7:35 PM, Tim Nguyen via webkit-dev
> <[email protected]> wrote:
>
> Hi!
>
> The protectedX() pattern hasn't bothered me much either. I’m inclined to not
> change it personally.
>
> There have been cases where it’s not super easy to adopt though, like when
> you have x.y->foo() and the x is a pair containing 2 pointers.
>
> In that case, I preferred `Ref { x.y }->foo()`, because it was hard to find
> an appropriate method name. I think this is the pattern I would prefer in
> cases where protectedX() is hard to adopt.
>
> Here’s an example where I’ve used that pattern:
> https://searchfox.org/wubkat/rev/021be8e5aefd8742e091c6369be13fd745207359/Source/WebCore/dom/ViewTransition.cpp#202,209
>
> Cheers,
> Tim
>
>> On Jan 13, 2026, at 2:50 PM, Chris Dumez via webkit-dev
>> <[email protected]> wrote:
>>
>> Hi,
>>
>> I have been doing a lot of safer cpp work and I can’t say that this issue
>> has been bothering me as much. They are real issues that I’ve had to deal
>> with though, I admit.
>>
>> To address the concerns raised by Geoff, I would prefer `Ref { x }->` over
>> `x()->protected()->`. It is more concise and something we already frequently
>> do (familiarity is nice). As a matter of fact, many people have been using
>> the rule of thumbs to use ``Ref { x }->` when there is no `protectedX()`
>> function available and if it is only needed once. We usually start
>> introducing a `protectedX()` function once we have more than one call site
>> for it. `x()->protected()->` is longer and it feels a bit weird to me to ask
>> an object for a protected version of itself.
>>
>> I don’t dislike the idea of having a free `protect()` function and doing
>> `protect(x)->` but this is not any shorter and I don’t think it brings much
>> value personally compared to `Ref { x }->`.
>>
>> Note that this will be quite a bit of refactoring now that we’ve introduced
>> so many protected getters.
>>
>> Best regards,
>> Chris Dumez.
>>
>>> On Jan 14, 2026, at 6:06 AM, Ryosuke Niwa <[email protected]> wrote:
>>>
>>>>
>>>> On Jan 13, 2026, at 1:57 PM, Geoff Garen <[email protected]> wrote:
>>>>
>>>> Hello SaferCPP enthusiasts,
>>>>
>>>> I'm finding it challenging to use the protectedX()-> pattern, especially
>>>> when fixing failures mechanically.
>>>>
>>>> You need to examine a lot of context to decide if RefPtr<X> protectedX() {
>>>> return x; } can be defined inline in the header or if X is
>>>> forward-declared. If X is forward-declared you need to analyze the
>>>> potential performance cost of an out-of-line function call. Very tricky to
>>>> do when we care about 0.25% with 98% confidence! Or analyze if you could
>>>> #include X.h without ballooning build times or causing a circular
>>>> dependency or causing some kind of verification failure I still don’t
>>>> understand on an Apple-internal bot. Very tricky to do across 9MM lines of
>>>> code and many platforms!
>>>>
>>>> You need to examine a lot of context to decide if there are enough uses of
>>>> x to justify making a protectedX() helper. This can change forwards and
>>>> backwards as you edit code.
>>>>
>>>> In our guidelines we say that we use this idiom to avoid declaring a local
>>>> variable unnecessarily.
>>>>
>>>> Here are two alternatives to consider, which provide the same benefit:
>>>> * Use Ref { x }->
>>>> * Use x()->protected()->
>>>>
>>>> I prefer Ref { x }-> because
>>>> * it does not require a local variable
>>>> * it tells my plainly what is happening
>>>>
>>>> But if consensus favors x()->protected()->, I think that solves my problem
>>>> too.
>>>
>>> One other alternative is `protected(x())->` which can bypass a null check
>>> on `x()`.
>>>
>>> (We could even bring back `makeRefPtr(x())` instead).
>>>
>>> - R. Niwa
>>
>> _______________________________________________
>> webkit-dev mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>
> _______________________________________________
> webkit-dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
webkit-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
