> On Jan 30, 2023, at 12:11 PM, Ryosuke Niwa via webkit-dev 
> <webkit-dev@lists.webkit.org> wrote:
>> On Jan 30, 2023, at 10:47 AM, Alexey Proskuryakov <a...@webkit.org> wrote:
>> Reviving this old thread, reading it again made me wish for two things:
>> - a wiki document that describes what we are trying to do, not just a thread 
>> which patches the proposal with clarifications;
> Yeah, let me go make one.

I’ve posted https://github.com/WebKit/WebKit/wiki/Smart-Pointer-Usage-Rules

>> - a discussion of why we can postpone figuring out what to do with 
>> containers (like Vector<Node*> or HashMap<RenderBox*, 
>> RenderFragmentContainer*>).
> This was probably an oversight on my part. The intention is to make member 
> variables / local variables of container type should also be using smart 
> pointers in its type: e.g. Vector<RefPtr<Node>> instead of Vector<Node*>. 
> WeakHashMap<RenderBox, WeakPtr<RenderFragmentContainer>> instead of 
> HashMap<RenderBox*, RenderFragmentContainer*>. I’ll try to clarify this in 
> the new doc I make.

Fixed in the new wiki documentation.

- R. Niwa

>>> 23 сент. 2020 г., в 1:54 PM, Jan Korous <jkor...@apple.com> написал(а):
>>> Hi all,
>>> I am an engineer at Security Tools team at Apple responsible for the 
>>> tooling support for this effort.
>>>> On Sep 23, 2020, at 12:34 PM, Darin Adler <da...@apple.com> wrote:
>>>>> On Sep 23, 2020, at 12:18 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
>>>>> There are quite a few cases where data members are references but then 
>>>>> those can also be replaced by a simple member function which retrieves 
>>>>> the value of the smart pointer member variable and returns a reference.
>>>> I think this should be an explicit recommendation in the project of 
>>>> refactoring to follow these rules.
>>>>> For now, a trivial function is defined as a member function defined in 
>>>>> the class declaration whose definition simply returns a member variable 
>>>>> (the result of get() or a copy if the member variable is a smart pointer).
>>>> That seems like a rule that’s too narrow. I would not want a function to 
>>>> become non-trivial just because I moved it from being inline within the 
>>>> class definition to an inline below the class definition in the same 
>>>> header.
>>>> This rule worries me a lot right now; it seems like it could result in an 
>>>> explosion of local variable copies of arguments.
>>>>> We probably also need to figure out a way to exempt all lambda functions 
>>>>> that never get stored anywhere. We have a bunch of helper functions like 
>>>>> WTF::map which just calls lambdas on each item while iterating over an 
>>>>> array, etc... and there is no need to create a separate Ref / RefPtr in 
>>>>> those cases since lambdas are never stored and re-used later.
>>>> Does seem important. I am pretty sure I have seen this concept in other 
>>>> languages. We often try to use const Function& for one type of lambda 
>>>> argument and Function&& for the other type, but that’s far from complete.
>>> Re: lambda captures - I think we have two ideas here.
>>> 1. Allow WeakPtr captures.
>>> This makes sense to do but it implies we have to add the notion of 
>>> ownership to the rules. The thing is that WeakPtr is safe on its own (and 
>>> technically reference-counted) but it can’t be used as a safety measure in 
>>> the way of RefPtr or Ref since it doesn’t own the memory (not even in a 
>>> shared manner).
>>> 2. Allow raw pointer/reference captures.
>>> This makes sense given you use generic algorithms in the codebase. I will 
>>> implement a new version of the checker - currently it is still based on 
>>> simple AST analysis and for this kind of reasoning we’ll need to use 
>>> symbolic execution in Clang Static Analyzer.
>>> Thanks,
>>> Jan
>>>> — Darin
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

webkit-dev mailing list

Reply via email to