Introduce rtc::Maybe<T>, which either contains a T or not.

webrtc/base/maybe.h

Index: webrtc/base/maybe.h
diff --git a/webrtc/base/maybe.h b/webrtc/base/maybe.h
new file mode 100644
index 0000000000000000000000000000000000000000..0fc1914ce285c6f307306e6f035d4d2c4d6bbee6
--- /dev/null
+++ b/webrtc/base/maybe.h
@@ -0,0 +1,114 @@
+/*
+ *  Copyright 2015 The WebRTC Project Authors. All rights reserved.
+ *
+ *  Use of this source code is governed by a BSD-style license
+ *  that can be found in the LICENSE file in the root of the source
+ *  tree. An additional intellectual property rights grant can be found
+ *  in the file PATENTS.  All contributing project authors may
+ *  be found in the AUTHORS file in the root of the source tree.
+ */
+
+#ifndef WEBRTC_BASE_MAYBE_H_
+#define WEBRTC_BASE_MAYBE_H_
+
+#include <algorithm>
+#include <utility>
+
+#include "webrtc/base/checks.h"
+
+namespace rtc {
+
+// Simple std::experimental::optional-wannabe. It either contains a T or not.
+// In order to keep the implementation simple and portable, this implementation
+// actually contains a (default-constructed) T even when it supposedly doesn't
+// contain a value; use e.g. rtc::scoped_ptr<T> instead if that's too
+// expensive.
+//
+// A moved-from Maybe<T> may only be destroyed. Specifically, you may not

[mgraczyk, 2015/10/20 02:44:44]

Why? I can't do this?

Maybe<T> x{10};
func(std::move(x));

x = 20;

.... use x again ...


Normally the rule is that moved-from values are left in a valid but unspecified
state.  That implies that they can be "re-used" by reassigning to them.

[kwiberg-webrtc, 2015/10/20 08:43:20]

Yeah, that's actually the case here too. I'll fix the wording. (The current
wording comes from an earlier attempt to simply make moved-from Maybe<T> not
contain a value, but that complicated the implementation too much.)

+// assume that it just doesn't contain a value anymore and can be reused.
+//
+// TODO(kwiberg): Get rid of this class when the standard library has
+// std::optional (and we're allowed to use it).
+template <typename T>
+class Maybe final {
+ public:
+  // Construct an empty Maybe.
+  Maybe() : has_value_(false) {}
+
+  // Construct a Maybe that contains a value.
+  explicit Maybe(const T& val) : value_(val), has_value_(true) {}

[mgraczyk, 2015/10/20 02:44:44]

These constructors are not explicit for std::experimental::optional.

This causes the following code to work with optional, but not with Maybe:

Maybe<int> maybe = 1;

Not sure whether or not you want that to work.

[kwiberg-webrtc, 2015/10/20 08:43:20]

I want it to work, but it means more style guide violations. My opinion is that
this sort of class is precisely where bending the style guide rules makes sense,
but I'd like more reviewers to weigh in. Fredrik already argued for not making
these implicit in an earlier comment.

[Andrew MacDonald, 2015/10/20 18:38:04]

Personally, I'd prefer the implicit conversions. ArraySlice in google3 is an
example of a utility class with the same feature.

Since you're modelling Maybe on experimental::optional, I think it's least
surprising if you follow its conventions.

[mgraczyk, 2015/10/20 19:10:23]

+1

[kwiberg-webrtc, 2015/10/20 21:11:59]

Swell. I'll restore the implicit conversions then.

+  explicit Maybe(T&& val) : value_(static_cast<T&&>(val)), has_value_(true) {}
+
+  // Copy and move constructors.
+  // TODO(kwiberg): =default the move constructor when MSVC supports it.

[Andrew MacDonald, 2015/10/20 01:54:30]

Ugh :(

[kwiberg-webrtc, 2015/10/20 08:43:20]

Yeah. C++11 says you're allowed to =default them, and it works in gcc and
clang...

+  Maybe(const Maybe&) = default;
+  Maybe(Maybe&& m)
+      : value_(static_cast<T&&>(m.value_)), has_value_(m.has_value_) {}
+
+  // Assignment. Note that we allow assignment from either Maybe<T> or plain T.
+  // TODO(kwiberg): =default the move assignment op when MSVC supports it.
+  Maybe& operator=(const Maybe&) = default;
+  Maybe& operator=(Maybe&& m) {
+    value_ = static_cast<T&&>(m.value_);
+    has_value_ = m.has_value_;
+    return *this;
+  }
+  Maybe& operator=(const T& val) {

[mgraczyk, 2015/10/20 02:44:44]

std::optional does not have this overload. 
http://en.cppreference.com/w/cpp/experimental/optional/operator%3D

I'm not sure why, because it does have the corresponding constructor.

[kwiberg-webrtc, 2015/10/20 08:43:20]

And since it will implicitly turn T into std::optional<T>, assigning a T to a
std::optional<T> would still work, right?

[Andrew MacDonald, 2015/10/20 18:38:04]

So if you remove explicit from Maybe's corresponding constructor, remove this
operator as well?

[mgraczyk, 2015/10/20 19:10:23]

Yes I believe this is not needed.

[kwiberg-webrtc, 2015/10/20 21:11:59]

I'll try it, and see if the test detects any changes in e.g. the number of
constructor calls. Conceptually at least, implicit conversion before assignment
means creating a temporary that didn't need creating with these assignment
operators.

[kwiberg-webrtc, 2015/10/20 21:26:00]

As expected, it works, but results in a temporary Maybe being created, moved
from, and destroyed. I'll keep these unless you object.

[mgraczyk, 2015/10/20 22:16:19]

Yes but I would be surprised if the temporary were not elided with optimization.
 Does the test run with optimization and still show an extra temporary created?

[kwiberg-webrtc, 2015/10/20 22:57:17]

Yes, the extra temp is created even with optimizations enabled. Isn't that
expected---this situation isn't one where copy elision is supposed to be
allowed, is it? It's allowed for copy/move construction, not copy/move
assignment.

+    value_ = val;
+    has_value_ = true;
+    return *this;
+  }
+  Maybe& operator=(T&& val) {
+    value_ = static_cast<T&&>(val);
+    has_value_ = true;
+    return *this;
+  }
+
+  friend void swap(Maybe& m1, Maybe& m2) {

[mgraczyk, 2015/10/20 02:44:44]

This trick might not work with some versions of the standard libraries that
don't use ADL.

http://stackoverflow.com/questions/11562/how-to-overload-stdswap#comment30080...

It's probably okay if it builds on all of our targets.

[kwiberg-webrtc, 2015/10/20 08:43:20]

This page says the standard library is supposed to use ADL:
http://en.cppreference.com/w/cpp/concept/Swappable
But maybe that's only true for C++11, or only true in theory...

Anyway, I thought the reason why the recommendation isn't just to specialize
std::swap for your type is that you can't do partial template specialization? In
other words, that it's impossible to specialize std::swap for Maybe<T> without
specifying a concrete T.

[mgraczyk, 2015/10/20 22:16:19]

The alternative would be to use a non-friend, non-member with the same
signature.  Yours is option #2, the alternative is option #1 in the following

http://en.cppreference.com/w/cpp/concept/Swappable

I like yours better, and there is no problem if it works on all the compilers we
care about.

[kwiberg-webrtc, 2015/10/20 22:57:18]

I see. And yes, the unit test for swap proves that we call Maybe's own swap and
not something else (since nothing else would be as efficient).

But I'm curious: when would having a non-member swap in the enclosing namespace
work, when the inline friend swap wouldn't?

[mgraczyk, 2015/10/21 00:57:18]

I can't think of any. From the SO answers I believe the problem was with
non-conforming compilers rather than libraries as I originally thought.

+    using std::swap;
+    swap(m1.value_, m2.value_);
+    swap(m1.has_value_, m2.has_value_);
+  }
+
+  // Conversion to bool to test if we have a value.
+  explicit operator bool() const { return has_value_; }
+
+  // Dereferencing. Only allowed if we have a value.
+  const T* operator->() const {
+    RTC_DCHECK(has_value_);
+    return &value_;
+  }
+  T* operator->() {
+    RTC_DCHECK(has_value_);
+    return &value_;
+  }
+  const T& operator*() const {
+    RTC_DCHECK(has_value_);
+    return value_;
+  }
+  T& operator*() {
+    RTC_DCHECK(has_value_);
+    return value_;
+  }

[mgraczyk, 2015/10/20 02:44:44]

It would probably be worthwhile to include value_or already. Most code I have
seen that uses optional also uses value_or.

We could also include value() and use RTC_CHECK instead of DHECK in value(). 
That gives callers a "safe" way to access the value if they desire.

[kwiberg-webrtc, 2015/10/20 08:43:20]

Sounds reasonable. But I don't understand why
std::experimental::optional::value_or has such a complicated type; I was
thinking of using T value_or(const T&) and T value_or(T&&). (IIRC, I can't do
anything fancy if *this is an rvalue because Microsoft.)
Yes, if we have value_or(), value() makes sense too.

[kwiberg-webrtc, 2015/10/20 13:35:30]

I ended up doing only const T& value_or(const T&) const. T&&
value_or(T&&) && would have been useful (since callers could then move
from the return value), but as I said before we can't use it (yet).

[mgraczyk, 2015/10/20 19:10:23]

Yes, without std::move() and library support your version will be as useful as
possible.

[kwiberg-webrtc, 2015/10/20 21:11:59]

Well, you can have rvalues without std::move. Consider e.g.

  Maybe<X> GetX();
  X x = GetX().value_or(X());

Both the Maybe and the default value are rvalues here, so T&& value_or(T&&) &&
would have been selected, allowing x to be move constructed. With just const T&
value_or(const T&) const available, it'll be copy constructed instead.

That said, value_or isn't likely to be useful with big types anyway, since you
unconditionally pay for constructing the default value. I toyed with the idea of
having it accept a functor that would create the default value on demand, but
again it would be too complex. One of the best things about this implementation
is how dead simple it is.

[mgraczyk, 2015/10/20 22:16:19]

I see and I agree that it is best to keep it simple.

+
+  // Equality tests. Two Maybes are equal if they contain equivalent values, or
+  // if they're both empty.
+  friend bool operator==(const Maybe& m1, const Maybe& m2) {
+    return m1.has_value_ && m2.has_value_ ? m1.value_ == m2.value_
+                                          : m1.has_value_ == m2.has_value_;
+  }
+  friend bool operator!=(const Maybe& m1, const Maybe& m2) {
+    return m1.has_value_ && m2.has_value_ ? m1.value_ != m2.value_

[Andrew MacDonald, 2015/10/20 01:54:30]

return !(m1 == m2)

is more typical?

[kwiberg-webrtc, 2015/10/20 08:43:20]

Yes. But, if I do that, then Maybe<T>::operator!= is implemented in terms of
T::operator==. This way, Maybe<T>::operator!= is implemented in terms of
T::operator!=. I guess this isn't likely to matter for a whole lot of Ts,
though, so would you still like me to change it?

[Andrew MacDonald, 2015/10/20 18:38:04]

No, I see why you did it this way now. Thanks for the explanation.

+                                          : m1.has_value_ != m2.has_value_;
+  }
+
+ private:
+  // Invariant: Unless *this has been moved from, value_ is default-initialized
+  // (or copied or moved from a default-initialized T) if !has_value_.
+  T value_;
+  bool has_value_;
+};
+
+}  // namespace rtc
+
+#endif  // WEBRTC_BASE_MAYBE_H_