> On Sep 1, 2017, at 10:09 AM, Chris Dumez <cdu...@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 <m...@apple.com >> <mailto:m...@apple.com>> wrote: >> >> >> >>> On Sep 1, 2017, at 9:30 AM, Brady Eidson <beid...@apple.com >>> <mailto:beid...@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@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto: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 webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev