[webkit-dev] Get rid of RefPtr, replace with std::optional<Ref>?

[Filip Pizlo]

> On Sep 1, 2017, at 10:09 AM, Chris Dumez <cdumez at apple.com> wrote:
> 
> I think std::optional<Ref<Type>> looks ugly. Also, unlike RefPtr<>, I do not think it is copyable. It is pretty neat to be able to capture a RefPtr<> by value in a lambda.
> Also, how do you convert it to a raw pointer? myOptionalRef.value_or(nullptr) would not work. Not sure there would be a nice way to do so.
> 
> Finally, the storage space argument from Maciej is a good one.

We could create a specialization for std::optional<Ref>.  Filed: https://bugs.webkit.org/show_bug.cgi?id=176228

That seems like a good idea separately from whether it should be used instead of RefPtr.  Even if we did have style prohibiting it, we might end up with such a type because of template specialization.

I can see cases were std::optional<Ref> works more naturally into the surrounding code than RefPtr.  That probably happens if your code is already based on Ref.  In my experience there’s a lot of inertia to these things - once some code uses RefPtr enough, it can be awkward to introduce Ref and perhaps vice versa.  I don’t find it very hard to switch between thinking in terms of Ref and RefPtr, so I don’t mind that our code uses both.  I wouldn’t agree with a style that encourages using std::optional<Ref> instead of RefPtr, but I also wouldn’t want to disallow it.

-Filip


>  
> --
>  Chris Dumez
> 
> 
> 
> 
>> On Sep 1, 2017, at 9:46 AM, Maciej Stachowiak <mjs at apple.com <mailto:mjs at apple.com>> wrote:
>> 
>> 
>> 
>>> On Sep 1, 2017, at 9:30 AM, Brady Eidson <beidson at apple.com <mailto:beidson at apple.com>> wrote:
>>> 
>>> I recently worked on a patch where - because of the organic refactoring of the patch over its development - I ended up with a std::optional<Ref> instead of a RefPtr.
>>> 
>>> A followup review after it had already landed pointed this out, and it got me to thinking:
>>> 
>>> Does RefPtr do anything for us today that std::optional<Ref> doesn’t?
>> 
>> The obvious things would be: uses less storage space, has a shorter name.
>> 
>>> 
>>> I kind of like the idea of replacing RefPtr with std::optional<Ref>. It makes it explicitly clear what object is actually holding the reference, and completely removes some of the confusion of “when should I use Ref vs RefPtr?"
>>> 
>>> Thoughts?
>>> 
>>> Thanks,
>>> ~Brady
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20170901/fc11024f/attachment.html>