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
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.
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
