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]
