+template <bool If, class T>
+using AddConstIf = _t<std::conditional<If, const T, T>>;
+
+template <class Fn, class A>
+FOLLY_ALWAYS_INLINE FOLLY_ATTR_VISIBILITY_HIDDEN
+auto fold(Fn&&, A&& a) {
+ return static_cast<A&&>(a);
+}
+
+template <class Fn, class A, class B, class... Bs>
+FOLLY_ALWAYS_INLINE FOLLY_ATTR_VISIBILITY_HIDDEN
+auto fold(Fn&& fn, A&& a, B&& b, Bs&&... bs) {
+ return fold(
+ // This looks like a use of fn after a move of fn, but in reality, this is
+ // just a cast and not a move. That's because regardless of which fold
+ // overload is selected, fn gets bound to a &&. Had fold taken fn by value
+ // there would indeed be a problem here.
+ static_cast<Fn&&>(fn),
+ static_cast<Fn&&>(fn)(static_cast<A&&>(a), static_cast<B&&>(b)),
+ static_cast<Bs&&>(bs)...);
+}
+
+} // namespace exception_wrapper_detail
+
+//! Throwing exceptions can be a convenient way to handle errors. Storing
+//! exceptions in an `exception_ptr` makes it easy to handle exceptions in a
+//! different thread or at a later time. `exception_ptr` can also be used in a
+//! very generic result/exception wrapper.
+//!
+//! However, there are some issues with throwing exceptions and
+//! `std::exception_ptr`. These issues revolve around `throw` being expensive,
+//! particularly in a multithreaded environment (see
+//! ExceptionWrapperBenchmark.cpp).
+//!
+//! Imagine we have a library that has an API which returns a result/exception
+//! wrapper. Let's consider some approaches for implementing this wrapper.
+//! First, we could store a `std::exception`. This approach loses the derived
+//! exception type, which can make exception handling more difficult for users
+//! that prefer rethrowing the exception. We could use a `folly::dynamic` for
+//! every possible type of exception. This is not very flexible - adding new
+//! types of exceptions requires a change to the result/exception wrapper. We
+//! could use an `exception_ptr`. However, constructing an `exception_ptr` as
+//! well as accessing the error requires a call to throw. That means that there
+//! will be two calls to throw in order to process the exception. For
+//! performance sensitive applications, this may be unacceptable.
+//!
+//! `exception_wrapper` is designed to handle exception management for both
+//! convenience and high performance use cases. `make_exception_wrapper` is
+//! templated on derived type, allowing us to rethrow the exception properly for
+//! users that prefer convenience. These explicitly named exception types can
+//! therefore be handled without any peformance penalty. `exception_wrapper` is
+//! also flexible enough to accept any type. If a caught exception is not of an
+//! explicitly named type, then `std::exception_ptr` is used to preserve the
+//! exception state. For performance sensitive applications, the accessor
+//! methods can test or extract a pointer to a specific exception type with very
+//! little overhead.
+//!
+//! \par Example usage:
+//! \par
+//! \code
+//! exception_wrapper globalExceptionWrapper;
+//!
+//! // Thread1
+//! void doSomethingCrazy() {
+//! int rc = doSomethingCrazyWithLameReturnCodes();
+//! if (rc == NAILED_IT) {
+//! globalExceptionWrapper = exception_wrapper();
+//! } else if (rc == FACE_PLANT) {
+//! globalExceptionWrapper = make_exception_wrapper<FacePlantException>();
+//! } else if (rc == FAIL_WHALE) {
+//! globalExceptionWrapper = make_exception_wrapper<FailWhaleException>();
+//! }
+//! }
+//!
+//! // Thread2: Exceptions are ok!
+//! void processResult() {
+//! try {
+//! globalExceptionWrapper.throw_exception();
+//! } catch (const FacePlantException& e) {
+//! LOG(ERROR) << "FACEPLANT!";
+//! } catch (const FailWhaleException& e) {
+//! LOG(ERROR) << "FAILWHALE!";
+//! }
+//! }
+//!
+//! // Thread2: Exceptions are bad!
+//! void processResult() {
+//! globalExceptionWrapper.handle(
+//! [&](FacePlantException& faceplant) {
+//! LOG(ERROR) << "FACEPLANT";
+//! },
+//! [&](FailWhaleException& failwhale) {
+//! LOG(ERROR) << "FAILWHALE!";
+//! },
+//! [](...) {
+//! LOG(FATAL) << "Unrecognized exception";
+//! });
+//! }
+//! \endcode
+class exception_wrapper final {
+ private:
+ struct AnyException : std::exception {
+ std::type_info const* typeinfo_;
+ template <class T>
+ /* implicit */ AnyException(T&& t) noexcept : typeinfo_(&typeid(t)) {}
+ };
+
+ template <class Fn>
+ struct arg_type_;
+ template <class Fn>
+ using arg_type = _t<arg_type_<Fn>>;
+
+ // exception_wrapper is implemented as a simple variant over four
+ // different representations:
+ // 0. Empty, no exception.
+ // 1. An small object stored in-situ.
+ // 2. A larger object stored on the heap and referenced with a
+ // std::shared_ptr.
+ // 3. A std::exception_ptr, together with either:
+ // a. A pointer to the referenced std::exception object, or
+ // b. A pointer to a std::type_info object for the referenced exception,
+ // or for an unspecified type if the type is unknown.
+ // This is accomplished with the help of a union and a pointer to a hand-
+ // rolled virtual table. This virtual table contains pointers to functions
+ // that know which field of the union is active and do the proper action.
+ // The class invariant ensures that the vtable ptr and the union stay in sync.
+ struct VTable {
+ void (*copy_)(exception_wrapper const*, exception_wrapper*);
+ void (*move_)(exception_wrapper*, exception_wrapper*);
+ void (*delete_)(exception_wrapper*);
+ void (*throw_)(exception_wrapper const*);
+ std::type_info const* (*type_)(exception_wrapper const*);
+ std::exception const* (*get_exception_)(exception_wrapper const*);
+ exception_wrapper (*get_exception_ptr_)(exception_wrapper const*);
+ };
+
+ [[noreturn]] static void onNoExceptionError();
+
+ template <class Ret, class... Args>
+ static Ret noop_(Args...);
+
+ static std::type_info const* uninit_type_(exception_wrapper const*);
+
+ static VTable const uninit_;