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]
