> 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]
