betfair casino rules_free login casino games online_Welfare offer letou gaming

Fri, 14 Dec 2018 14:05:07 -0800


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

- Saam 

> 
>> 
>> - 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@lists.webkit.org <mailto:webkit-dev@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@lists.webkit.org <mailto:webkit-dev@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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to