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]
