[Webkit-unassigned] [Bug 192728] New: wtf/Optional.h: move-constructor and move-assignment operator should disengage the value being moved from

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=192728

            Bug ID: 192728
           Summary: wtf/Optional.h: move-constructor and move-assignment
                    operator should disengage the value being moved from
           Product: WebKit
           Version: WebKit Local Build
          Hardware: Unspecified
               URL: https://lists.webkit.org/pipermail/webkit-dev/2018-Dec
                    ember/030316.html
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Template Framework
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: ddkilzer at webkit.org
                CC: aperez at igalia.com, cdumez at apple.com,
                    fujii.hironori at gmail.com, jfbastien at apple.com,
                    sbarati at apple.com, youennf at gmail.com

This is the same as Bug 163309, but now with a different std::optional implementation.

In  <https://lists.webkit.org/pipermail/webkit-dev/2018-December/030316.html>, Chris Dumez writes:
'''
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
'''

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181215/b5dd3422/attachment.html>