> On Dec 14, 2018, at 1:56 PM, Saam Barati <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.
> > - 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
