> On Dec 14, 2018, at 1:59 PM, Chris Dumez <cdu...@apple.com> wrote: > >> >> On Dec 14, 2018, at 1:56 PM, Saam Barati <sbar...@apple.com >> <mailto:sbar...@apple.com>> wrote: >> >> >> >>> On Dec 14, 2018, at 1:54 PM, Saam Barati <sbar...@apple.com >>> <mailto:sbar...@apple.com>> wrote: >>> >>> >>> >>>> On Dec 14, 2018, at 1:37 PM, Chris Dumez <cdu...@apple.com >>>> <mailto:cdu...@apple.com>> wrote: >>>> >>>> Hi, >>>> >>>> I have now been caught twice by std::optional’s move constructor. It turns >>>> out that it leaves the std::optional being moved-out *engaged*, it merely >>>> moves its value. >>>> >>>> For example, testOptional.cpp: >>>> #include <iostream> >>>> #include <optional> >>>> >>>> int main() >>>> { >>>> std::optional<int> a = 1; >>>> std::optional<int> b = std::move(a); >>>> std::cout << "a is engaged? " << !!a << std::endl; >>>> std::cout << "b is engaged? " << !!b << std::endl; >>>> return 0; >>>> } >>>> >>>> $ clang++ testOptional.cpp -o testOptional -std=c++17 >>>> $ ./testOptional >>>> a is engaged? 1 >>>> b is engaged? 1 >>>> >>>> I would have expected: >>>> a is engaged? 0 >>>> b is engaged? 1 >>> I would have expected this too. >>> >>>> >>>> This impacts the standard std::optional implementation on my machine as >>>> well as the local copy in WebKit’s wtf/Optional.h. >>>> >>>> As far as I know, our convention in WebKit so far for our types has been >>>> that types getting moved-out are left in a valid “empty” state. >>> I believe it's UB to use an object after it has been moved. >> I'm wrong here. >> Apparently objects are left in a "valid but unspecified state". >> >> https://stackoverflow.com/questions/32346143/undefined-behavior-with-stdmove >> <https://stackoverflow.com/questions/32346143/undefined-behavior-with-stdmove> > I believe in WebKit, however, we’ve made sure our types are left in a valid > “empty” state, thus my proposal for our own optional type that would be less > error-prone / more convenient to use. I think your proposal is reasonable. I agree it's less error prone.
I think if we make this change, we should pull optional out of std and put it in WTF, since we're now implementing behavior we will rely on being specified. - Saam > >> >> - Saam >>> >>> - Saam >>> >>>> As such, I find that std::optional’s move constructor behavior is >>>> error-prone. >>>> >>>> I’d like to know how do other feel about this behavior? If enough people >>>> agree this is error-prone, would we consider having our >>>> own optional type in WTF which resets the engaged flag (and never allow >>>> the std::optional)? >>>> >>>> Thanks, >>>> -- >>>> Chris Dumez >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> webkit-dev mailing list >>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >>>> https://lists.webkit.org/mailman/listinfo/webkit-dev >>>> <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 >>> <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
