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

[Chris Dumez]

> On Dec 14, 2018, at 1:56 PM, Saam Barati <sbarati at apple.com> wrote:
> 
> 
> 
>> On Dec 14, 2018, at 1:54 PM, Saam Barati <sbarati at apple.com <mailto:sbarati at apple.com>> wrote:
>> 
>> 
>> 
>>> On Dec 14, 2018, at 1:37 PM, Chris Dumez <cdumez at apple.com <mailto:cdumez at 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 at lists.webkit.org <mailto:webkit-dev at 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 at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20181214/7af8430f/attachment.html>