Hello, On Fri, 14 Dec 2018 14:02:39 -0800, Saam Barati <sbar...@apple.com> wrote: > > 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 is also what I would have expected. > >>>> 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. I am also in favor of having an implementation in WTF that empties the optional after moving the value out from it. Cheers, -Adrián
pgpE_fxSDMoUF.pgp
Description: PGP signature
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
