[webkit-dev] Watch out for std::optional's move constructor

[youenn fablet]

Is it too late to ask for a std::optional change?

Le ven. 14 déc. 2018 à 13:37, Chris Dumez <cdumez at apple.com> a écrit :
>
> 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 at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev