WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch
(2.78 KB, patch)
2021-05-23 22:33 PDT
,
Cameron McCormack (:heycam)
darin
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Cameron McCormack (:heycam)
Comment 1
2021-05-23 22:12:24 PDT
Created
attachment 429502
[details]
Patch
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
Created
attachment 429503
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug