I would vote for `protect(x)` for the naming, which is even shorter and still clear IMO.
> On Jan 22, 2026, at 9:25 AM, Chris Dumez via webkit-dev > <[email protected]> wrote: > > I don’t think `protected(x)` works because “protected” is a C++ keyword. > > I tried building this: > ``` > template<typename T> > T* protected(const T& ref) { > return &ref; > } > int main() { > int x = 5; > protected(x); > return 0; > } > ``` > And I got: > ``` > test_protected_keyword.cpp:2:4: error: expected unqualified-id > 2 | T* protected(const T& ref) { > | ^ > test_protected_keyword.cpp:8:5: error: expected expression > 8 | protected(x); > | ^ > 2 errors generated. > ``` > I think we need to find another name? After reflection, I do prefer a free > function because it is annoying at call sites to figure out if we need Ref { > } or RefPtr { }. > > Chris. > >> On Jan 22, 2026, at 7:27 AM, Geoff Garen <[email protected]> wrote: >> >> 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]
_______________________________________________ webkit-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
