RESOLVED CONFIGURATION CHANGED 226161
typo in `Optional<T&>::value() const` prevents usage of `Optional<const T&>`
https://bugs.webkit.org/show_bug.cgi?id=226161
Summary typo in `Optional<T&>::value() const` prevents usage of `Optional<const T&>`
Cameron McCormack (:heycam)
Reported 2021-05-23 22:07:11 PDT
.
Attachments
Patch (1.09 KB, patch)
2021-05-23 22:12 PDT, Cameron McCormack (:heycam)
no flags
Patch (2.78 KB, patch)
2021-05-23 22:33 PDT, Cameron McCormack (:heycam)
darin: review+
Cameron McCormack (:heycam)
Comment 1 2021-05-23 22:12:24 PDT
Myles C. Maxfield
Comment 2 2021-05-23 22:13:20 PDT
Comment on attachment 429502 [details] Patch Please add a test. (TestWTF)
Cameron McCormack (:heycam)
Comment 3 2021-05-23 22:33:11 PDT
Myles C. Maxfield
Comment 4 2021-05-23 22:41:14 PDT
Comment on attachment 429503 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=429503&action=review > Tools/TestWebKitAPI/Tests/WTF/Optional.cpp:253 > + Optional<int&> optional { x }; In all the places where you want to use an optional reference, you should just be using a pointer instead. You shouldn't have hit this problem in the first place.
Cameron McCormack (:heycam)
Comment 5 2021-05-23 22:50:03 PDT
Using `const T*` works for me. Should the Optional<T&> specialization be removed? There are a few places in the codebase that use Optional<T&>, specifically Optional<JSObject&>. Yusuke, looks like you added the Optional<T&> specialization. Do you think it's really needed, or should we just be using JSObject* in these cases? I thought perhaps this was for completeness when compared to std::optional, but https://en.cppreference.com/w/cpp/utility/optional says: There are no optional references; a program is ill-formed if it instantiates an optional with a reference type.
Darin Adler
Comment 6 2021-05-23 22:53:28 PDT
Comment on attachment 429503 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=429503&action=review >> Tools/TestWebKitAPI/Tests/WTF/Optional.cpp:253 >> + Optional<int&> optional { x }; > > In all the places where you want to use an optional reference, you should just be using a pointer instead. You shouldn't have hit this problem in the first place. I agree with this comment. As a style choice we encourage continuing to use pointers for optional references.
Chris Dumez
Comment 7 2021-05-23 22:56:43 PDT
(In reply to Cameron McCormack (:heycam) from comment #5) > Using `const T*` works for me. Should the Optional<T&> specialization be > removed? > > There are a few places in the codebase that use Optional<T&>, specifically > Optional<JSObject&>. Yusuke, looks like you added the Optional<T&> > specialization. Do you think it's really needed, or should we just be using > JSObject* in these cases? > > I thought perhaps this was for completeness when compared to std::optional, > but https://en.cppreference.com/w/cpp/utility/optional says: > > There are no optional references; a program is ill-formed if it > instantiates an > optional with a reference type. Indeed, it appears std::optional doesn't support this: https://www.fluentcpp.com/2018/10/05/pros-cons-optional-references/ Maybe we should just get rid of the functionality altogether in WTF::Optional? Let's see what Yusuke has to say since he added it. I do agree that a T* makes more sense than an Optional<T&>.
Darin Adler
Comment 8 2021-05-23 22:57:01 PDT
(In reply to Cameron McCormack (:heycam) from comment #5) > I thought perhaps this was for completeness when compared to std::optional, > but https://en.cppreference.com/w/cpp/utility/optional says: > > There are no optional references; a program is ill-formed if it > instantiates an > optional with a reference type. Very interesting! I would like our WTF::Optional to match std::optional and I intend to switch us off of it. You can see a brief debate in bug 211674 where Chris Dumez suggests that our different semantic of guaranteeing a WTF::Optional is set to WTF::nullopt when moving from it is a reason to stay with WTF::Optional. I’d like to resolve that issue and dump WTF::Optional entirely as soon as we can. In the mean time, I suggest we minimize differences from std::optional, which points to removing our support for optional references.
Chris Dumez
Comment 9 2021-05-23 23:01:13 PDT
(In reply to Darin Adler from comment #8) > (In reply to Cameron McCormack (:heycam) from comment #5) > > I thought perhaps this was for completeness when compared to std::optional, > > but https://en.cppreference.com/w/cpp/utility/optional says: > > > > There are no optional references; a program is ill-formed if it > > instantiates an > > optional with a reference type. > > Very interesting! > > I would like our WTF::Optional to match std::optional and I intend to switch > us off of it. You can see a brief debate in bug 211674 where Chris Dumez > suggests that our different semantic of guaranteeing a WTF::Optional is set > to WTF::nullopt when moving from it is a reason to stay with WTF::Optional. > I’d like to resolve that issue and dump WTF::Optional entirely as soon as we > can. I think we've been advocating using std::exchange() for a while now. We can probably try and switch to std::optional. Hopefully, use-after-move won't be as much as an issue this time around. > In the mean time, I suggest we minimize differences from std::optional, > which points to removing our support for optional references. +1
Darin Adler
Comment 10 2021-05-25 14:50:56 PDT
This is obsolete now, because I removed the contents of Optional.hhttps://bugs.webkit.org/show_bug.cgi?id=226161#
Note You need to log in before you can comment on or make changes to this bug.