> On Dec 14, 2018, at 1:37 PM, Chris Dumez <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. - 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 > 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