> On Dec 14, 2018, at 3:52 PM, Chris Dumez <cdu...@apple.com
> <mailto:cdu...@apple.com>> wrote:
>
> So to be clear, it is often not truly about using the value after it is
> moved. It is about expecting that the variable / member has been nulled out
> after moving it.
> If I WTFMove() out a data member m_dataMember, I expect later on `if
> (m_dataMember)` to be false.
>
I do not mean to derail the discussion about whether or not we should have our
own std::optional that disengages on move. I am all for convenience. I think
expecting a valid “empty” state (*) when moving out a data member is an
anti-pattern and I propose that we should be using std::exchange() instead (or
any code analogous to doing std::exchange()) for these cases, including the
case in your original email and especially with data members as in
<https://trac.webkit.org/changeset/239228
<https://trac.webkit.org/changeset/239228>>.
Why do I consider it an anti-pattern? See (*) and because the concept of
“moving" is not spec'ed to behave like this. Here’s one reference to the
spec’ed behavior and an example comparable to the one in your first email
(highlighting is my own for emphasis):
[[
Unless otherwise specified, all standard library objects that have been moved
from are placed in a valid but unspecified state. That is, only the functions
without preconditions, such as the assignment operator, can be safely used on
the object after it was moved from:
std::vector <http://en.cppreference.com/w/cpp/container/vector><std::string
<http://en.cppreference.com/w/cpp/string/basic_string>> v;
std::string <http://en.cppreference.com/w/cpp/string/basic_string> str =
"example";
v.push_back(std::move(str)); // str is now valid but unspecified
str.back(); // undefined behavior if size() == 0: back() has a precondition
!empty()
str.clear(); // OK, clear() has no preconditions
]]
<https://en.cppreference.com/w/cpp/utility/move
<https://en.cppreference.com/w/cpp/utility/move>>
(*) What is the valid “empty” state for a type without a default constructor?
Dan
> --
> Chris Dumez
>
>
>
>
>> On Dec 14, 2018, at 3:45 PM, Chris Dumez <cdu...@apple.com
>> <mailto:cdu...@apple.com>> wrote:
>>
>>
>>> On Dec 14, 2018, at 3:39 PM, Fujii Hironori <fujii.hiron...@gmail.com
>>> <mailto:fujii.hiron...@gmail.com>> wrote:
>>>
>>>
>>> On Sat, Dec 15, 2018 at 6:38 AM Chris Dumez <cdu...@apple.com
>>> <mailto:cdu...@apple.com>> wrote:
>>>
>>> I have now been caught twice by std::optional’s move constructor.
>>>
>>> I don't understand how this could be useful? Do you want to use the value
>>> after it is moved? I'd like to see these your code. Could you show me these
>>> two patches?
>>
>> This is the latest one: https://trac.webkit.org/changeset/239228/webkit
>> <https://trac.webkit.org/changeset/239228/webkit>
>>
>>
>> _______________________________________________
>> 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
