P0080R0.latex

\documentclass[11pt]{article}

\usepackage{color}
\usepackage{xcolor}
\usepackage{fullpage}
\usepackage[colorlinks, allcolors=blue]{hyperref}
\usepackage{listings}
\usepackage{parskip}
\usepackage{url}
\usepackage{courier}
\usepackage[T1]{fontenc}
% \usepackage{libertine}%% Only as example for the romans/sans fonts
\usepackage[scaled=0.85]{beramono}
\usepackage{changepage}
\usepackage{nameref}

% Solarized colour scheme for listings
\definecolor{solarized@base03}{HTML}{002B36}
\definecolor{solarized@base02}{HTML}{073642}
\definecolor{solarized@base01}{HTML}{586e75}
\definecolor{solarized@base00}{HTML}{657b83}
\definecolor{solarized@base0}{HTML}{839496}
\definecolor{solarized@base1}{HTML}{93a1a1}
\definecolor{solarized@base2}{HTML}{EEE8D5}
\definecolor{solarized@base3}{HTML}{FDF6E3}
\definecolor{solarized@yellow}{HTML}{B58900}
\definecolor{solarized@orange}{HTML}{CB4B16}
\definecolor{solarized@red}{HTML}{DC322F}
\definecolor{solarized@magenta}{HTML}{D33682}
\definecolor{solarized@violet}{HTML}{6C71C4}
\definecolor{solarized@blue}{HTML}{268BD2}
\definecolor{solarized@cyan}{HTML}{2AA198}
\definecolor{solarized@green}{HTML}{859900}

\lstset{
  basicstyle=\footnotesize\ttfamily,
}

% Define C++ syntax highlighting colour scheme
\lstdefinelanguage{cpp}{
  language=C++,
  basicstyle=\footnotesize\ttfamily,
  numbers=left,
  numberstyle=\footnotesize,
  tabsize=2,
  breaklines=true,
  escapeinside={@}{@},
  numberstyle=\tiny\color{solarized@base01},
  keywordstyle=\color{solarized@green},
  stringstyle=\color{solarized@cyan}\ttfamily,
  identifierstyle=\color{solarized@blue},
  commentstyle=\color{solarized@base01},
  emphstyle=\color{solarized@red},
  frame=single,
  rulecolor=\color{solarized@base2},
  rulesepcolor=\color{solarized@base2},
  showstringspaces=false,
}

\lstdefinelanguage{diff}{
  morecomment=[f][\color{blue}]{@@},           % group identifier
  morecomment=[f][\color{red}]{-},             % deleted lines
  morecomment=[f][\color{green!50!black}]{+},  % added lines
  morecomment=[f][\color{magenta}]{---},       % diff header lines
  morecomment=[f][\color{magenta}]{+++},
}

\lstdefinelanguage{plus}{
  basicstyle=\footnotesize\ttfamily\color{green!50!black},
  emph={see,below,TypeSwitch,unspecified},
  emphstyle=\itshape
}

\lstdefinelanguage{signature}{
  basicstyle=\ttfamily\color{green!50!black},
  emph={see,below,TypeSwitch,unspecified},
  emphstyle=\itshape
}

\newcommand{\desc}[1]{\textit{#1}}
\newcommand{\requires}{\desc{Requires}}
\newcommand{\effects}{\desc{Effects}}
\newcommand{\precondition}{\desc{Precondition}}
\newcommand{\postcondition}{\desc{Postcondition}}
\newcommand{\throws}{\desc{Throws}}
\newcommand{\returns}{\desc{Returns}}
\newcommand{\remarks}{\desc{Remarks}}
\newcommand{\exceptionsafety}{\desc{Exception Safety}}

\newcommand{\fullref}[1]{\ref{#1} \nameref{#1}}

\date{}
\title{Variant: Discriminated Union with Value Semantics}

\newcommand{\emailaddress}{mcypark@gmail.com}
\newcommand{\email}{\href{mailto:\emailaddress}{\emailaddress}}

\begin{document}

\maketitle\vspace{-2cm}

\begin{flushright}
  \begin{tabular}{ll}
  Document \#:&P0080\\
  Date:       &\date{2015-07-28}\\
  Project:    &Programming Language C++\\
              &Library Evolution Group\\
  Reply-to:   &\author{Michael Park}\\
              &\textless\email\textgreater
  \end{tabular}
\end{flushright}

{\hypersetup{linkcolor=black}
  \tableofcontents
}

\section{Introduction}
This paper is an alternative proposal to \cite{N4542}, which proposes a design
for a discriminated union. This topic has been discussed \textbf{extensively}
within the ISO C++ Standards Committee as well as \textbf{std-proposals} mailing
list. The goal of this paper is to identify the concerns of the polarizing groups,
and to propose a solution that would address them with minimal compromise.

\section{Motivation and Scope}
Due to the lack of discriminated union with value semantics in C++, they are
typically handled in one of 3 ways:

\begin{itemize}
  \item \texttt{union}-like class, with an \texttt{enum} as the
    discriminator
  \item Class inheritance hierarchy
  \item \texttt{enum}, in the special case where all alternatives are simply
    unit types.
\end{itemize}

\subsection{\texttt{union}-like Class}
A \texttt{union}-like class typically consists of the \texttt{union} which
contains one of the possible alternatives, and an \texttt{enum} that represents
the discriminator.

\begin{lstlisting}[language=cpp]
struct Token {
  Token(int i) : int_(i), type(Int) {}
  Token(std::string s) : string_(std::move(s)), type(String) {}

  ~Token() {
    switch (type) {
      case Int:
        break;
      case String:
        using std::string;
        string_.~string();
        break;
    }
  }

  enum { Int, String } type;
  union {
    int int_;
    std::string string_;
  };
};
\end{lstlisting}

Note that after all of this code, this class still only supports construction
and destruction. Even more code would need to be written to support other
operations such as element access, assignment, visitation, etc.

Furthermore, it still only handles exactly one set of types: \texttt{int} and
\texttt{std::string}. A whole new class definition would need to be written for
a different set of types consisting of more or less the exact same code.

\subsection{Class Inheritance Hierarchy}
A class inheritance is a discriminated union in the sense that a pointer to an
abstract base class can only be pointing to an instance of one of the derived
classes.

\begin{lstlisting}[language=cpp]
struct Token {};
struct Int : Token { int value; };
struct String : Token { std::string value; };
\end{lstlisting}

There are several disadvantages to this approach:
\begin{itemize}
  \item \texttt{Token} no longer has value semantics. It must be passed around
    by pointer or reference in order to avoid object slicing.
  \item \texttt{Int}, and \texttt{String} classes needed to be introduced since
    \texttt{int} and \texttt{std::string} cannot inherit from \texttt{Token}.
  \item If a type needs to be a member of multiple discriminated unions,
    multiple inheritance needs to be introduced.
  \item The use of virtual functions typically scatters the individual cases
    for a single algorithm into different parts of the codebase which becomes
    an engineering burden. The visitor pattern is a popular solution to this
    problem and also makes it possible for multi-visitation, but it introduces
    non-trivial amount of boilerplate code only to support exactly one set of
    types.
\end{itemize}

\subsection{\texttt{enum}}
In the special case where the members of a discriminated union do not have
associated data, an \texttt{enum} is typically used to achieve the behavior.

\begin{lstlisting}[language=cpp]
enum class Color { Blue, Green, Red };
\end{lstlisting}

This paper proposes a library solution for a generic, type-safe discriminated
union with value semantics with the class template \texttt{variant<Types...>}.

The following is an example of how the library may be used:

\begin{lstlisting}[language=cpp]
#include <iostream>
#include <string>
#include <variant>

struct custom_equal {
  template <class T>
  bool operator()(const T& lhs, const T& rhs) const { return lhs == rhs; }

  template <class T, class U>
  bool operator()(const T&, const U&) const { return false; }
};

int main() {
  using namespace std::string_literals;

  // direct initialization
  std::variant<int, std::string> v("hello world!"s);

  // direct access
  const std::string& s = std::get<std::string>(v);
  assert(s == "hello world!"s);

  try {
    int i = std::get<int>(v);  // throws: std::bad_variant_access
  } catch (const std::bad_variant_access& ex) {
    // handle exception
  }

  // copy (and move) construction
  std::variant<int, std::string> w(v);

  // assignment
  try {
    v = 42;
  } catch (const std::bad_variant_assign& ex) {
    // `v` is in an indeterminate state. The exception thrown by the move
    // constructor is available as `ex.nested_ptr`.
  } catch (const std::exception& ex) {
    // v is valid.
  }

  // visitation
  std::type_switch (v) (
    [](const auto& value) { std::cout << value; }
  );  // prints: 42

  std::type_switch (w) (
    [](int value               ) { std::cout << "int: "    << value; },
    [](const std::string& value) { std::cout << "string: " << value; }
  );  // prints: string: hello world!

  bool result = std::type_switch (v, w) (custom_equal{});
  assert(!result);

  std::type_switch (v, w) (
    [](int               , int               ) { std::cout << "(int, int)"      ; },
    [](int               , const std::string&) { std::cout << "(int, string)"   ; },
    [](const std::string&, int               ) { std::cout << "(string, int)"   ; },
    [](const std::string&, const std::string&) { std::cout << "(string, string)"; }
  );  // prints: (int, string)
\end{lstlisting}

The support for discriminated unions are common in many other languages such as
Haskell, ML, Rust, Swift, and F\#.

\section{Impact on the Standard}
This proposal is a pure library extension, and does not require any new language
features.

\section{Proposed Wording}
Make the following changes to the experimental \texttt{<optional>} header:

\begin{lstlisting}[language=diff]
namespace std {
-  constexpr in_place_t in_place{};
+  in_place_t in_place() { return {}; }

-  template <class... Args> constexpr explicit optional(in_place_t, Args&&...);
+  template <class... Args> constexpr explicit optional(in_place_t (&)(), Args&&...);

   template <class U, class... Args>
-  constexpr explicit optional(in_place_t, initializer_list<U>, Args&&...);
+  constexpr explicit optional(in_place_t (&)(), initializer_list<U>, Args&&...);
}
\end{lstlisting}

Add a new subclause \texttt{20.N Variants} under \texttt{20 General utilities library:}

{\color{green!50!black}
\paragraph{20.N Variants}\hfill\textbf{[variant]}
\paragraph{20.N.1 In general}\hfill\textbf{[variant.general]}

This subclause describes the \texttt{variant} library that provides a
discriminated union as the class template \texttt{variant}. Each template argument
specifies the type of an element that can be stored in the \texttt{variant}
object.

Header \texttt{<variant>} synopsis:
}

\begin{lstlisting}[language=plus]
namespace std {
  // 20.N.2 class template variant:
  template <class... Types> class variant;

  // 20.N.3 class bad_variant_access:
  class bad_variant_access;

  // 20.N.4 class bad_variant_assign:
  class bad_variant_assign;

  // 20.N.5 in-place construction:
  template <size_t I> in_place_t in_place(integral_constant<size_t, I>) { return {}; }
  template <class T> in_place_t in_place(T) { return {}; }

  // 20.N.6 nullvar:
  struct nullvar_t {};
  constexpr nullvar_t nullvar{};

  // 20.N.7 element access:
  template <size_t I, class... Types>
  constexpr remove_reference_t<tuple_element_t<I, tuple<Types...>>>* get(
      variant<Types...>*) noexcept;

  template <size_t I, class... Types>
  constexpr remove_reference_t<const tuple_element_t<I, tuple<Types...>>>* get(
      const variant<Types...>*) noexcept;

  template <class T, class... Types>  // only if see below
  constexpr remove_reference_t<T>* get(variant<Types...>*) noexcept;

  template <class T, class... Types>  // only if see below
  constexpr remove_reference_t<const T>* get(const variant<Types...>*) noexcept;

  template <size_t I, class... Types>
  constexpr tuple_element_t<I, tuple<Types...>>& get(variant<Types...>&);

  template <size_t I, class... Types>
  constexpr const tuple_element_t<I, tuple<Types...>>& get(const variant<Types...>&);

  template <size_t I, class... Types>
  constexpr tuple_element_t<I, tuple<Types...>>&& get(variant<Types...>&&);

  template <size_t I, class... Types>
  constexpr const tuple_element_t<I, tuple<Types...>>&& get(const variant<Types...>&&);

  template <class T, class... Types>
  constexpr T& get(variant<Types...>&);  // only if see below

  template <class T, class... Types>
  constexpr const T& get(const variant<Types...>&);  // only if see below

  template <class T, class... Types>
  constexpr T&& get(variant<Types...>&&);  // only if see below

  template <class T, class... Types>
  constexpr const T&& get(const variant<Types...>&&);  // only if see below

  // 20.N.8 relational operators:
  constexpr bool operator==(nullvar_t, nullvar_t) { return true;  }
  constexpr bool operator!=(nullvar_t, nullvar_t) { return false; }
  constexpr bool operator< (nullvar_t, nullvar_t) { return false; }
  constexpr bool operator> (nullvar_t, nullvar_t) { return false; }
  constexpr bool operator<=(nullvar_t, nullvar_t) { return true;  }
  constexpr bool operator>=(nullvar_t, nullvar_t) { return true;  }

  template <class... Types>
  constexpr bool operator==(const variant<Types...>&, const variant<Types...>&);

  template <class... Types>
  constexpr bool operator!=(const variant<Types...>&lhs,
                            const variant<Types...>&rhs) { return !(lhs == rhs); }

  template <class... Types>
  constexpr bool operator<(const variant<Types...>&, const variant<Types...>&);

  template <class... Types>
  constexpr bool operator>(const variant<Types...>&lhs,
                           const variant<Types...>&rhs) { return rhs < lhs; }

  template <class... Types>
  constexpr bool operator<=(const variant<Types...>&lhs,
                            const variant<Types...>&rhs) { return !(lhs > rhs); }

  template <class... Types>
  constexpr bool operator>=(const variant<Types...>&lhs,
                            const variant<Types...>&rhs) { return !(lhs < rhs); }


  // 20.N.9 specialized algorithms:
  template <class... Types>
  void swap(variant<Types...>& lhs,
            variant<Types...>& rhs) noexcept(noexcept(lhs.swap(rhs)));

  // 20.N.10 hash support:
  template <> struct hash<nullvar_t>;
  template <class... Types> struct hash<variant<Types...>>;

  // 20.N.11 visitation:
  template <class R = unspecified:deduce_tag, class... Variants>
  unspecified:TypeSwitch<R, Variants...> type_switch(Variants&&...);
}
\end{lstlisting}

{\color{green!50!black}
\paragraph{20.N.2 Class template \texttt{variant}}\hfill\textbf{[variant.variant]}
}

\begin{lstlisting}[language=plus]
namespace std {
  template <class... Types>
  class variant {
  public:
    // 20.N.2.1 variant construction:
    constexpr variant() noexcept;

    template <size_t I, class... Args>
    explicit constexpr variant(in_place_t (&)(integral_constant<size_t, I>),
                               Args&&...);

    template <size_t I, class U, class... Args>  // only if see below
    explicit constexpr variant(in_place_t (&)(integral_constant<size_t, I>),
                               initializer_list<U>,
                               Args&&...);

    template <class T, class... Args>
    explicit constexpr variant(in_place_t (&)(T), Args&&...);


    template <class T, class U, class... Args>  // only if see below
    explicit constexpr variant(in_place_t (&)(T), initializer_list<U>, Args&&...);

    template <class U> constexpr variant(U&&);  // only if see below

    variant(const variant&);
    variant(variant&&) noexcept(see below);

    // 20.N.2.2 variant destruction:
    ~variant();

    // 20.N.2.3 variant assignment:
    template <size_t I, class... Args> void emplace(Args&&...);

    template <size_t I, class U, class... Args>
    void emplace(initializer_list<U>, Args&&...);  // only if see below

    template <class T, class... Args> void emplace(Args&&...);

    template <class T, class U, class... Args>
    void emplace(initializer_list<U>, Args&&...);  // only if see below

    template <class U> variant& operator=(U&&);  // only if see below

    variant& operator=(const variant&);
    variant& operator=(variant&&) noexcept(see below);

    // 20.N.2.4 variant observers:
    constexpr int index() const noexcept;
    constexpr const type_info& type() const noexcept;

    // 20.N.2.5 variant swap:
    void swap(variant&) noexcept(see below);
  };
}
\end{lstlisting}

{\color{green!50!black}
\paragraph{20.N.2.1 Construction}\hfill\textbf{[variant.cnstr]}

For each \texttt{variant} constructor, an exception is thrown only if the
construction of one of the types in \texttt{Types...} throws an exception.
}

\begin{lstlisting}[language=signature]
constexpr variant() noexcept;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}
\effects: Constructs the \texttt{variant} object in an indeterminate state.
\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <size_t I, class... Args>
explicit constexpr variant(in_place_t (&)(integral_constant<size_t, I>),
                           Args&&... args);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}
Let \texttt{T} be the type \texttt{tuple\_element\_t<I, tuple<Types...>{}>}.

\requires: \texttt{I < sizeof...(Types) \&\& is\_constructible\_v<T, Args\&\&...>} is
\texttt{true}

\effects: Initializes the contained value of the \texttt{variant} as if constructing an
object of type \texttt{T} with \texttt{forward<Args>(args)...}.

\postcondition: \texttt{index() == I}

\throws: Any exception thrown by the selected constructor of \texttt{T}.

\remarks: If the selected constructor of \texttt{T} is a \texttt{constexpr} constructor,
this constructor shall be a \texttt{constexpr} constructor.
\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <size_t I, class U, class... Args>  // only if see below
explicit constexpr variant(in_place_t (&ip)(integral_constant<size_t, I>),
                           initializer_list<U> init,
                           Args&&... args);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Equivalent to

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
template <size_t I, class... Args>
explicit constexpr variant(
    in_place_t (&)(integral_constant<size_t, I>), Args&&...);
\end{lstlisting}
\end{adjustwidth}
}

with arguments \texttt{ip, init, forward<Args>(args)...}

\remarks: This constructor shall not participate in overload resolution unless\\
\texttt{is\_constructible\_v< tuple\_element\_t<I, tuple<Types...>{}>,\\
initializer\_list<U>\&, Args\&\&...>} is \texttt{true}. If the selected constructor of
\texttt{T} is a \texttt{constexpr} constructor, this constructor shall be a
\texttt{constexpr} constructor.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class T, class... Args>
explicit constexpr variant(in_place_t (&)(T), Args&&... args);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{I} be the index of \texttt{T} in \texttt{Types...}

\requires: \texttt{T} is in \texttt{Types... \&\& T} is unique within
\texttt{Types....}

\effects: Equivalent to \texttt{variant(in\_place<I>, forward<Args>(args)...);}

\remarks: If the selected constructor of \texttt{T} is a \texttt{constexpr} constructor,
this constructor shall be a \texttt{constexpr} constructor.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class T, class U, class... Args>  // only if see below
explicit constexpr variant(in_place_t (&ip)(T),
                           initializer_list<U> init,
                           Args&&... args);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Equivalent to

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
template <class T, class... Args>
explicit constexpr variant(in_place_t (&)(T), Args&&...);
\end{lstlisting}
\end{adjustwidth}
}

with arguments \texttt{ip, init, forward<Args>(args)...}

\remarks: This constructor shall not participate in overload resolution unless\\
\texttt{is\_constructible\_v<T, initializer\_list<U>\&, Args\&\&...>} is \texttt{true}.
If the selected constructor of \texttt{T} is a \texttt{constexpr} constructor,
this constructor shall be a \texttt{constexpr} constructor.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class U>
constexpr variant(U&& u);  // only if see below
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{T} be one of the types in \texttt{Types...} for which \texttt{U\&\&} is
unambiguously convertible to by standard overload resolution rules.

\effects: Equivalent to \texttt{variant(in\_place<T>, forward<U>(u));}

\remarks: This constructor shall not participate in overload resolution unless
there is a type \texttt{T} in \texttt{Types...} for which \texttt{U\&\&} is
unambiguously convertible to by standard overload resolution rules. If the selected
constructor of \texttt{T} is a \texttt{constexpr} constructor, this constructor shall
be a \texttt{constexpr} constructor.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
variant(const variant& that);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{I} be the constant expression of \texttt{that.index()}.

Let \texttt{T} be \texttt{tuple\_element\_t<I, tuple<Types...>{}>}.

\requires: \texttt{is\_copy\_constructible\_v<U>} is \texttt{true} for all
\texttt{U} in \texttt{Types...}

\effects: Initializes the contained value of the \texttt{variant} as if constructing
an object of type \texttt{T} with \texttt{get<I>(that)}.

\postcondition: \texttt{index() == I}

\throws: Any exception thrown by the selected constructor of \texttt{T}.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
variant(variant&& that) noexcept(see below);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{I} be the constant expression of \texttt{that.index()}

Let \texttt{T} be \texttt{tuple\_element\_t<I, tuple<Types...>{}>}

\requires: \texttt{is\_move\_constructible\_v<U>} is \texttt{true} for all
\texttt{U} in \texttt{Types...}

\effects: Initializes the contained value of the \texttt{variant} as if
constructing an object of type \texttt{T} with \texttt{get<I>(std::move(that))}.

\postcondition: \texttt{index() == I}

\throws: Any exception thrown by the selected constructor of \texttt{T}.

\remarks: The expression inside \texttt{noexcept} is equivalent to the logical
\texttt{AND} of\\
\texttt{is\_nothrow\_move\_constructible\_v<U>} for all \texttt{U} in \texttt{Types...}

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.2.2 Destruction}\hfill\textbf{[variant.dtor]}
}

\begin{lstlisting}[language=signature]
~variant();
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{I} be the constant expression of \texttt{index()}

Let \texttt{T} be \texttt{tuple\_element\_t<I, tuple<Types...>{}>}

\effects: If the \texttt{variant} is initialized, calls
\texttt{get<I>(*this).$_{\widetilde{~}}$T();}

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.2.3 Assignment}\hfill\textbf{[variant.assign]}

For each \texttt{variant} assignment operation, an exception is thrown only if the
construction of one of the types in \texttt{Types...} throws an exception.
}

\begin{lstlisting}[language=signature]
template <size_t I, class... Args> void emplace(Args&&...);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{T} be the type \texttt{tuple\_element\_t<I, tuple<Types...>{}>}.

\requires: \texttt{is\_constructible\_v<T, Args\&\&...>} is \texttt{true}

\effects: Destructs the value in \texttt{*this}, then initializes the contained
value of \texttt{*this} as if constructing an object of type \texttt{T} with the
arguments \texttt{forward<Args>(args)...}

\postcondition: \texttt{index() == I}

\throws: \texttt{bad\_variant\_assign} or any exception thrown by the selected
constructor of \texttt{T}.

\exceptionsafety: If an exception \texttt{E} is thrown during the initialization
of the value in \texttt{*this}, \texttt{E} is caught and \texttt{bad\_variant\_assign}
is thrown with \texttt{E} nested within it. In this case, no initialization takes place
and \texttt{variant} is left in an indeterminate state. Otherwise, there are no effects.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <size_t I, class U, class... Args>
void emplace(initializer_list<U> init, Args&&... args);  // only if see below
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Equivalent to

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
template <size_t I, class... Args> void emplace(Args&&...);
\end{lstlisting}
\end{adjustwidth}
}

with arguments \texttt{init, forward<Args>(args)...}

\remarks: Let \texttt{T} be the type \texttt{tuple\_element\_t<I,
tuple<Types...>{}>}. This function shall not participate in overload resolution unless
\texttt{is\_constructible\_v<T, initializer\_list<U>\&, Args\&\&...>} is
\texttt{true}.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class T, class... Args> void emplace(Args&&...);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{I} be the index of \texttt{T} in \texttt{Types...}

\requires: \texttt{T} is in \texttt{Types... \&\& T} is unique within \texttt{Types...}.

\effects: Equivalent to \texttt{emplace(in\_place<I>, forward<Args>(args)...)};

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class T, class U, class... Args>
void emplace(initializer_list<U> init, Args&&...);  // only if see below
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Equivalent to

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
template <class T, class... Args> void emplace(Args&&...);
\end{lstlisting}
\end{adjustwidth}
}

with arguments \texttt{init, forward<Args>(args)...}

\remarks: This constructor shall not participate in overload resolution unless\\
\texttt{is\_constructible\_v<T, initializer\_list<U>\&, Args\&\&...>} is \texttt{true}.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class U> variant& operator=(U&&);  // only if see below
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{T} be one of the types in \texttt{Types...} for which
\texttt{U\&\&} is unambiguously convertible to by standard overload resolution rules.

\requires: \texttt{is\_constructible\_v<T, U\&\&>} is \texttt{true \&\&
is\_assignable\_v<T, U\&\&>} is \texttt{true}

\effects: If \texttt{*this} contains a value of type \texttt{T}, effectively performs

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
get<T>(*this) = forward<U>(u);
\end{lstlisting}
\end{adjustwidth}
}

Otherwise, if \texttt{is\_nothrow\_constructible\_v<T, U\&\&>} is \texttt{true}, performs

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
emplace<T>(forward<U>(u);
\end{lstlisting}
\end{adjustwidth}
}

Otherwise, performs

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
emplace<T>(T(forward<U>(u));  // Note the temporary construction.
\end{lstlisting}
\end{adjustwidth}
}

\returns: \texttt{*this}

\remarks: This constructor shall not participate in overload resolution unless
there is a type \texttt{T} in \texttt{Types...} for which \texttt{U\&\&} is
unambiguously convertible to by standard overload resolution rules.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
variant& operator=(const variant& that);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{I} be the constant expression of \texttt{that.index()}

Let \texttt{T} be \texttt{tuple\_element\_t<I, tuple<Types...>{}>}

\requires: \texttt{is\_copy\_constructible\_v<U>} is \texttt{true \&\&
is\_copy\_assignable\_v<U>} for all \texttt{U} in \texttt{Types...}

\effects: Equivalent to \texttt{return *this = get<I>(that);}

\returns: \texttt{*this}

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
variant& operator=(variant&& that) noexcept(see below);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{I} be the constant expression of \texttt{that.index()}

Let \texttt{T} be \texttt{tuple\_element\_t<I, tuple<Types...>{}>}

\requires: \texttt{is\_move\_constructible\_v<U>} is \texttt{true \&\&
is\_move\_assignable\_v<U>} for all \texttt{U} in \texttt{Types...}

\effects: Equivalent to \texttt{return *this = get<I>(std::move(that));}

\returns: \texttt{*this}

\remarks: The expression inside \texttt{noexcept} is equivalent to the logical
\texttt{AND} of\\
\texttt{is\_nothrow\_move\_constructible\_v<U> \&\& is\_nothrow\_move\_assignable\_v<U>}
for all \texttt{U} in \texttt{Types...}

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.2.4 Observers}\hfill\textbf{[variant.observers]}
}

\begin{lstlisting}[language=signature]
constexpr int index() const noexcept;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Returns the index of the currently active alternative.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
constexpr const type_info& type() const noexcept;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{I} be the constant expression of \texttt{index()}

Let \texttt{T} be \texttt{tuple\_element\_t<I, tuple<Types...>{}>}

\effects: Returns \texttt{typeid(T)}

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.2.5 Swap}\hfill\textbf{[variant.swap]}
}

\begin{lstlisting}[language=signature]
void swap(variant& that) noexcept(see below);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{I} be the constant expression of \texttt{index()}

Let \texttt{T} be \texttt{tuple\_element\_t<I, tuple<Types...>{}>}

\requires: \texttt{is\_move\_constructible\_v<U>} is \texttt{true} and \texttt{U}
shall satisfy the requirements of\\
\texttt{Swappable} for all \texttt{U} in \texttt{Types...}

\effects: If \texttt{index() == that.index()}, performs

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
using std::swap;
swap(get<I>(*this), get<I>(that));
\end{lstlisting}
\end{adjustwidth}
}

Otherwise, equivalent to calling

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
template <class T> void swap(T&, T&);
\end{lstlisting}
\end{adjustwidth}
}

with arguments \texttt{*this, that}

\exceptionsafety: If an exception was thrown during the call to function
\texttt{swap(get<I>(*this), get<I>(that))}, the state of the value of
\texttt{*this} and that is determined by the exception safety guarantee of
\texttt{swap} for \texttt{T}.

If an exception was thrown during the call to \texttt{swap(*this, that)}, the
state of the value of \texttt{*this} and \texttt{that} is determined by the exception
safety guarantee of \texttt{variant}'s move constructor and assignment operator.

\remarks: The expression inside \texttt{noexcept} is equivalent to the logical
\texttt{AND} of\\
\texttt{is\_nothrow\_move\_constructible\_v<U> \&\&\\
noexcept(iter\_swap(declval<U*>(), declval<U*>))} for all \texttt{U} in
\texttt{Types...}

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.3 Class \texttt{bad\_variant\_access}}
\hfill\textbf{[variant.bad.variant.access]}
}

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
namespace std {
  class bad_variant_access : public exception {
  public:
    explicit bad_variant_access();
    bad_variant_access(const bad_variant_access&) noexcept;
    bad_variant_access& operator=(const bad_variant_access&) noexcept;
    virtual const char* what() const noexcept;
  };
}
\end{lstlisting}
\end{adjustwidth}
}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}
The class \texttt{bad\_variant\_access} defines the type of objects thrown as
exceptions to report the situation where an invalid attempt is made to access
the value of a \texttt{variant} via \texttt{get}.

Given an object \texttt{v} of type \texttt{variant<Types...>},

\begin{itemize}
  \item For index-based operations, \texttt{get<I>(v)} is invalid if
    \texttt{get<I>(\&v) == nullptr}
  \item For type-based operations, \texttt{get<T>(v)} is invalid if
    \texttt{get<T>(\&v) == nullptr}
\end{itemize}
\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
explicit bad_variant_access();
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Constructs an object of class \texttt{bad\_variant\_access}.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
bad_variant_access(const bad_variant_access&) noexcept;
bad_variant_access& operator=(const bad_variant_access&) noexcept;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Copies an object of class \texttt{bad\_variant\_access}.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
virtual const char* what() const noexcept;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\returns: An implementation-defined NTBS.

\remarks: The message may be a null-terminated multibyte string (17.5.2.1.4.2),
suitable for conversion and display as a \texttt{wstring} (21.3, 22.4.1.4).

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.4 Class \texttt{bad\_variant\_assign}}
\hfill\textbf{[variant.bad.variant.assign]}
}

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
namespace std {
  class bad_variant_assign : public exception, public nested_exception {
  public:
    bad_variant_assign(void*) noexcept;
    bad_variant_assign(const bad_variant_assign&) noexcept;
    bad_variant_assign& operator=(const bad_variant_assign&) noexcept;
    void* variant_ptr() const noexcept;
    virtual const char* what() const noexcept;
  };
}
\end{lstlisting}
\end{adjustwidth}
}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}
The class \texttt{bad\_variant\_assign} defines the type of objects thrown as nested
exceptions to report the situation where an exception was thrown during an
assignment (i.e. \texttt{operator=}, \texttt{emplace}) into a \texttt{variant} object
and is left in an indeterminate state.
\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
bad_variant_assign(void* v_ptr) noexcept;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Constructs an object of class \texttt{bad\_variant\_assign}.

\postcondition: \texttt{variant\_ptr() == v\_ptr}.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
bad_variant_assign(const bad_variant_assign&) noexcept;
bad_variant_assign& operator=(const bad_variant_assign&) noexcept;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Copies an object of class \texttt{bad\_variant\_assign}.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
void* variant_ptr() const noexcept;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\returns: The pointer to the \texttt{variant} that is left in an indeterminate state.

\remarks: If multiple \texttt{variant} objects are left in the indeterminate state
during the propagation of \texttt{bad\_variant\_assign}, the pointers to those
variants will be captured within nested \texttt{bad\_variant\_assign} exceptions.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
virtual const char* what() const noexcept;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\returns: An implementation-defined NTBS.

\remarks: The message may be a null-terminated multibyte string (17.5.2.1.4.2),
suitable for conversion and display as a \texttt{wstring} (21.3, 22.4.1.4).

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.5 In-Place Construction}\hfill\textbf{[variant.in.place]}
}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\texttt{in\_place} is an overloaded function used to disambiguate the overloads of
constructors and member functions of that take arguments (possibly a parameter pack)
for in-place construction.

\texttt{variant} has constructors with

\begin{itemize}
  \item \texttt{decltype(in\_place<I>) == in\_place\_t (\&)(integral\_constant<size\_t, I>)}
    as the first parameter which indicates that an object of type
    \texttt{tuple\_element\_t<I, variant<Types...>{}>} should be constructed in-place.
  \item \texttt{decltype(in\_place<T>) == in\_place\_t (\&)(T)} as the first parameter
    indicates that an object of type \texttt{T} should be constructed in-place.
\end{itemize}

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.6 Null Variant}\hfill\textbf{[variant.nullvar]}
}

\begin{lstlisting}[language=signature]
struct nullvar_t {};
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\texttt{nullvar\_t} is an empty class type used as an alternative of a
\texttt{variant} which allows the user to opt-in for the presence of a conceptual
representation of the empty state.
[ \textit{Note}: The class template \texttt{variant} does not provide any special behavior
for \texttt{nullvar\_t}. The result of this is that \texttt{variant} behaves consistently
with any custom representation of the empty state. --- \textit{end note} ]

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
constexpr nullvar_t nullvar{};
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\texttt{nullvar} is a constant of type \texttt{nullvar\_t} that is used as an alternative
of a \texttt{variant} which allows the user to opt-in for the presence of a conceptual
representation of the empty state.

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.7 Element Access}\hfill\textbf{[variant.elem]}
}

\begin{lstlisting}[language=signature]
template <size_t I, class... Types>
constexpr remove_reference_t<tuple_element_t<I, tuple<Types...>>>* get(
    variant<Types...>* v) noexcept;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Equivalent to

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
using T = tuple_element_t<I, tuple<Types...>>
return const_cast<remove_reference_t<T>*>(
    get<I>(static_cast<const variant<Types...>*>(v)));
\end{lstlisting}
\end{adjustwidth}
}

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <size_t I, class... Types>
constexpr remove_reference_t<const tuple_element_t<I, tuple<Types...>>>* get(
    const variant<Types...>* v) noexcept;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{J} be the constant expression of \texttt{v.index()}.

\requires: \texttt{I < sizeof...(Types)}

\returns: A pointer to the contained value of \texttt{v} if
\texttt{v != nullptr \&\& I == J} else \texttt{nullptr}

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class T, class... Types>
constexpr remove_reference_t<T>* get(variant<Types...>* v) noexcept;

template <class T, class... Types>
constexpr remove_reference_t<const T>* get(const variant<Types...>* v) noexcept;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{I} be the index of \texttt{T} in \texttt{Types...}.

\requires: \texttt{T} is in \texttt{Types... \&\& T} is unique within \texttt{Types...}.

\effects: Equivalent to \texttt{return get<I>(v)}

\returns: \texttt{get<I>(v)}

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <size_t I, class... Types>
constexpr tuple_element_t<I, tuple<Types...>>& get(variant<Types...>& v);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Equivalent to

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
using T = tuple_element_t<I, tuple<Types...>>;
return const_cast<T&>(
    get<I>(static_cast<const variant<Types...>&>(v)));
\end{lstlisting}
\end{adjustwidth}
}

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <size_t I, class... Types>
constexpr const tuple_element_t<I, tuple<Types...>>& get(
    const variant<Types...>& v);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Equivalent to

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
auto *result = get<I>(&v);
return result ? *result : throw bad_variant_access{};
\end{lstlisting}
\end{adjustwidth}
}

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <size_t I, class... Types>
constexpr tuple_element_t<I, tuple<Types...>>&& get(variant<Types...>&& v);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Equivalent to

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
using T = tuple_element_t<I, tuple<Types...>>;
return static_cast<T&&>(get<I>(v));
\end{lstlisting}
\end{adjustwidth}
}

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <size_t I, class... Types>
constexpr const tuple_element_t<I, tuple<Types...>>&& get(
    const variant<Types...>&& v);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Equivalent to

{
\begin{adjustwidth}{2em}{}
\begin{lstlisting}[language=signature]
using T = tuple_element_t<I, tuple<Types...>>;
return static_cast<const T&&>(get<I>(v));
\end{lstlisting}
\end{adjustwidth}
}

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class T, class... Types>
constexpr T& get(variant<Types...>& v);

template <class T, class... Types>
constexpr const T& get(const variant<Types...>& v);

template <class T, class... Types>
constexpr T&& get(variant<Types...>&& v);

template <class T, class... Types>
constexpr const T&& get(const variant<Types...>&& v);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{I} be the index of \texttt{T} in \texttt{Types...}.

\requires: \texttt{T} is in \texttt{Types... \&\& T} is unique within \texttt{Types...}

\effects: Equivalent to \texttt{return get<I>(v);}

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.8 Relational Operators}\hfill\textbf{[variant.rel]}
}

\begin{lstlisting}[language=signature]
template <class... Types>
constexpr bool operator==(const variant<Types...>&lhs,
                          const variant<Types...>&rhs);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\requires: For all \texttt{I} where \texttt{I} \(\in\)
  \texttt{[0, sizeof...(Types\textsubscript{I})]}, \texttt{get<I>(lhs) == get<I>(rhs)}
  is a valid expression returning a type that is convertible to \texttt{bool}.

\returns: \texttt{true} if \texttt{lhs.index() == rhs.index() \&\&
  get<I>(lhs) == get<I>(rhs)} where \texttt{I} is the constant expression of
  \texttt{lhs.index()}, otherwise \texttt{false}.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class... Types>
constexpr bool operator<(const variant<Types...>&lhs,
                         const variant<Types...>&rhs);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\requires: For all \texttt{I} where \texttt{I} \(\in\)
  \texttt{[ 0, sizeof...(Types\textsubscript{I})]}, \texttt{get<I>(lhs) < get<I>(rhs)}
  is a valid expression returning a type that is convertible to \texttt{bool}.

\returns: \texttt{true} if \texttt{std::tie(lhs.index(), get<I>(lhs)) <\\
  std::tie(rhs.index(), get<I>(rhs))} where \texttt{I} is the constant expression of
  \texttt{lhs.index()}, otherwise \texttt{false}.

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.9 Specialized Algorithms}\hfill\textbf{[variant.special]}
}

\begin{lstlisting}[language=signature]
template <class... Types>
void swap(variant<Types...>& lhs,
          variant<Types...>& rhs) noexcept(noexcept(lhs.swap(rhs)));
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Equivalent to \texttt{lhs.swap(rhs)}.

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.10 Hash Support}\hfill\textbf{[variant.hash]}
}

\begin{lstlisting}[language=signature]
template <> struct hash<nullvar_t>;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

The template specialization shall meet the requirement of class template
\texttt{hash} (20.9.13).

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class... Types> struct hash<variant<Types...>>;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\requires: The template specialization \texttt{hash<U>} shall meet the requirements
of class template \texttt{hash} (20.9.13) for all \texttt{U} in \texttt{Types...}

The template specialization shall meet the requirement of class template
\texttt{hash} (20.9.13).

\end{adjustwidth}
}

{\color{green!50!black}
\paragraph{20.N.11 Visitation}\hfill\textbf{[variant.visit]}
}

\begin{lstlisting}[language=signature]
template <class R = unspecified:deduce_tag, class... Variants>
unspecified:TypeSwitch<R, Variants&&...> type_switch(Variants&&... vs);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Constructs a callable object \textit{\texttt{TypeSwitch}} which holds references
to \texttt{forward<Variants>(vs)...}. Because the result may contain references to
temporary variables, a program shall ensure that the return value of this function does
not outlive any of its arguments. (e.g., the program should typically not store
the result in a named variable).

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class R, class... Variants>
struct TypeSwitch {
  explicit TypeSwitch(Variants...);

  template <class F>
  see below TypeSwitch::operator()(F&&) const;

  template <class... Fs>
  see below TypeSwitch::operator()(Fs&&...) const;

  template <template <class...> class F, class... Args>
  see below TypeSwitch::operator()(const typed_visitor<F, Args...>&) const;
};
\end{lstlisting}

\begin{lstlisting}[language=signature]
explicit TypeSwitch(Variants... vs);
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Holds references to \texttt{vs...}.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class F>
see below TypeSwitch::operator()(F&& f) const;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

Let \texttt{vs...} be the references to instances of \texttt{Variants...} that
\textit{\texttt{TypeSwitch}} holds.

Let \texttt{Variant\textsubscript{I}} be the \texttt{I\textsuperscript{th}} type
in \texttt{decay\_t<Variants>{}>...}.

Let \texttt{Types\textsubscript{I}...} be the template parameter pack
\texttt{Types...} of \texttt{Variant\textsubscript{I}}.

\requires: \texttt{invoke(forward<F>(f),
  get<I\textsubscript{0}>(v\textsubscript{0}), ...,
  get<I\textsubscript{N}>(v\textsubscript{N})) OR
  forward<F>(f).template operator()<I\textsubscript{0}, ...,
  I\textsubscript{N}>(get<I\textsubscript{0}>(v\textsubscript{0}), ...,
  get<I\textsubscript{N}>(v\textsubscript{N}))}
  must be a valid expression for all \texttt{I\textsubscript{I}} where
  \texttt{I\textsubscript{I}} \(\in\) \texttt{[ 0, sizeof...(Types\textsubscript{I})]}.

\effects: Let \texttt{Is...} be the constant expression of
  \texttt{vs.index()...}. Equivalent to \texttt{forward<F>(f).template
  operator()<Is...>(get<Is>(vs)...)} if it is a valid expression, otherwise
  equivalent to \texttt{invoke(forward<F>(f), get<Is>(vs)...)};

\remarks: If \texttt{!is\_same\_v<R, \textit{unspecified}:deduce\_tag>} is
  \texttt{true}, the return type of this function is \texttt{R}.

  Otherwise, if \texttt{decay\_t<F>} contains a member typedef
  \texttt{result\_type}, the return type is
  \texttt{typename decay\_t<F>::result\_type}.

  Otherwise, the return type is deduced by \texttt{decltype(auto)}.

\end{adjustwidth}
}

\begin{lstlisting}[language=signature]
template <class... Fs>
see below TypeSwitch::operator()(Fs&&... fs) const;
\end{lstlisting}

{
\begin{adjustwidth}{2em}{}
\color{green!50!black}

\effects: Equivalent to \texttt{(*this)(overload(forward<Fs>(fs)...));  // P0051}

\end{adjustwidth}
}

\section{Terminology}
\label{terminology}
This section clearly defines some of the terminology used within this paper.
There were some discrepancy around the understanding of terms such as
\texttt{discriminated union}, \texttt{sum type}, \texttt{empty state}, and
\texttt{null state}. It will be worthwhile to be accurately define them for clear
and efficient communication.

\subsection{Discriminated Union vs Sum Type}
In set theory, a \texttt{discriminated union} (or disjoint union) of a family of sets
\(S_{0}, S_{1}, ..., S_{N}\) is a modified union operation that augments the elements
with the index of the originating set. Formally, this is defined as:
\(\sqcup S_{i} = \cup \{ (x, i) : x \in S_{i} \}\).
For example, \(S_{0} = \{ 1, 2, 3 \}\) and \(S_{1} = \{ 1, 2 \}\),
\(S_{0} \sqcup S_{1} = \{ (1, 0), (2, 0), (3, 0), (1, 1), (2, 1) \}\).

In type theory, a sum type of a family of types \(T_{0}, T_{1}, ..., T_{N}\) is a
discriminated union of the types, except that augmentation is typically done with a name,
rather than an index. In functional languages such as Haskell and OCaml, the name is
represented as a type constructor. For example, the declaration of a sum type
\texttt{Int + String} is required to be tagged with a name like so:
\texttt{data Identifier = Id Int | Name String}, where \texttt{Id} is the tag of
\texttt{Int} and \texttt{Name} is the tag of \texttt{String}.
The notation for sum type is typically \texttt{T0 + T1} which derives from the sum
relationship of the cardinality of the types: \(|T0 + T1| = |T0| + |T1|\).

\subsection{Empty State}
A state in which the \texttt{variant} has none of its alternatives constructed.

\subsection{Null State}
A state in which the \texttt{variant} contains a value that represents the
conceptual emptiness of a variant. All operations are valid.
For example, the user must explicitly handle the null case for
the visitation operation.

\subsection{Valid, but Unspecified State}
\label{emptyvbus}
A state in which the \texttt{variant} has none of its alternatives constructed,
but the discriminator of the \texttt{variant} is in a specified state.
The valid operations in this state are: assignment (e.g. \texttt{operator=},
\texttt{emplace}), destruction, observation (e.g. \texttt{index}, \texttt{valid}),
copy and move construction.

[ \textit{Example}: If an object \texttt{v} of type
\texttt{std::variant<Types...>} is in a valid, but unspecified state,
\texttt{v.index()} can be called unconditionally, but \texttt{get<I>(v)} can be
called only if \texttt{v.index() >= 0} is \texttt{true}.
--- \textit{end example} ]

\subsection{Indeterminate State}
A state in which the \texttt{variant} has none of its alternatives constructed,
and the discriminator of the \texttt{variant} is also in an unspecified state.
The only valid operations in this state are: assignment (e.g.  \texttt{operator=},
\texttt{emplace}), and destruction. Any other operations performed in this state
have undefined behavior.

\section{Design Decisions}
\label{designdecisions}

\subsection{Empty State}
As defined in \fullref{terminology}, an empty state of a
\texttt{variant} is a state where none of the alternatives are constructed.
The following is an example that illustrates the problem:

\begin{lstlisting}[language=cpp]
std::variant<T, U> v(T(/* ... */));
U u;
v = u;
\end{lstlisting}

When \texttt{v} is assigned with \texttt{u}, it must destroy the contained value
of type \texttt{T} and in-place construct a value of type \texttt{U}.
If an exception is thrown during the construction \texttt{U}, \texttt{v} would be in
an empty state, since it has already destroyed the initial value of type \texttt{T}.

The following subsections describe the various strategies considered to handle
the exceptional case which can arise when some alternatives have move
constructors that can throw. Note that out of all the design discussions of a
standardized \texttt{variant}, this is the most contentious issue. Each approach
has at least one disadvantage which is claimed absolutely unacceptable to a
group of people. The goal of this paper is to choose a design that minimize the
compromises, and also to leave enough room for extensibility for those who
absolutely do not agree. The strategy proposed in this paper is mentioned last,
highlighted in {\color{solarized@blue}blue}.

\subsubsection{Additional Requirements on Alternatives}
The general theme of this subsection is to enforce additional requirements on
the alternatives. There are various additional requirements which can be enforced
to varying degrees.

For example, we could add additional requirements such as (1) all alternatives must be
nothrow move constructible, or (2) all alternatives must be nothrow default constructible
and nothrow swappable.

If the additional requirements are not satisfied, we could (1) disallow
\texttt{variant} as a whole, or (2) delete the assignment operations.

\textbf{Exception Safety}: Strong

\textbf{Pros}: New types should have nothrow move constructors, and provides
strong exception safety guarantee.

\textbf{Cons}: Regardless of whether most new types should be nothrow move constructible
or not, the standard library is (and should continue to be) resilient to the existence
of types with move constructors that can throw. The standard library currently actively
supports types with move constructors that can throw (e.g.
\texttt{std::vector::push\_back}) by use of utility functions such as
\texttt{std::move\_if\_noexcept}.

Furthermore, the conditions in which a type can throw during its move construction is not
as rare as we would like. The following are conditions in which a move can throw:

\begin{itemize}
  \item Types in the standard library with move constructors that can throw
    (e.g. \texttt{std::set}),
  \item Legacy types that do not have a move constructor would fall-back to copy
    construction which can throw. This may be a type that the user can add a
    \texttt{noexcept} move constructor to, but it may also be an external library type
    that the user has no control over.
  \item All \texttt{const}-qualified types. A type with \texttt{noexcept} move constructor
    (e.g.  \texttt{std::string}) can throw during a move construction if it is
    \texttt{const}-qualified (e.g. \texttt{const std::string}).
\end{itemize}

\subsubsection{Double Storage}
The general theme of this subsection is to require double storage in situations where
additional requirements are not satisfied by the alternatives. It could be applied in
varying degrees within the spectrum of "minimize the cases in which double storage is
introduced" to "always use double storage".

Currently, the narrowest condition known to require double storage is if at
least \texttt{two} alternatives can throw during move construction.

\textbf{Exception Safety}: Strong

\textbf{Pros}: Under conditions in which double storage is required, people
should accept their fate in having to pay for the performance penalties.

Also, this is an issue that can be deferred as an implementation detail which
will continue to improve over time, and such implementation detail should not
hinder the interface.

\textbf{Cons}: While the double storage strategy could be seen as an implementation detail
that should not affect the interface, I would argue that \texttt{std::vector}'s
contiguous memory guarantee could also be seen as an implementation detail that should not
have affected the interface. Consider the exception safety specification of
\texttt{std::vector::push\_back}:

\begin{quote}
If the \texttt{T}'s move constructor is not \texttt{noexcept} and \texttt{T} is
not \texttt{CopyInsertable} into \texttt{*this}, \texttt{std::vector} will use the
throwing move constructor. If it throws, the strong exception safety guarantee is waived
and the effects are unspecified.
\end{quote}

If \texttt{std::vector} was designed without the contiguous memory guarantee which could
have been seen as an "implementation detail", it would have ended up similar to
\texttt{std::deque} where \texttt{push\_back} would always have strong exception
safety guarantee.

The point is that giving up single storage in some cases for \texttt{std::variant} would
be analogous to giving up contiguous memory in some cases for \texttt{std::vector}.

\subsubsection{Null State as a Required Alternative}
As defined in \fullref{terminology}, a null state is a state in which
\texttt{variant} contains a value that represents the conceptual emptiness of a
\texttt{variant}. This approach is to make the null state a required state of a
\texttt{variant}. This requirement could be enforced implicitly or explicitly:

\begin{itemize}
  \item \textbf{Implicit}: \texttt{nullvar\_t} is always implicitly injected as an
    alternative. That is, \texttt{variant<int, std::string>} holds one of
    \texttt{int}, \texttt{std::string}, or \texttt{nullvar\_t}
  \item \textbf{Explicit}: \texttt{nullvar\_t} is required to always explicitly be
    provided as an alternative. That is, \texttt{variant<int, std::string>} is not
    allowed. Must always provide \texttt{nullvar\_t}.
\end{itemize}

This approach is analogous to a pointer, and therefore inherits all of the
characteristics of a pointer. The following are arguments for and against
regarding the inherited characteristics.

\textbf{Exception Safety}: Basic

\textbf{Pros}: This approach is simple, and analogous to a pointer which is a well
understood primitive of the language, and people know how to deal with them.

\textbf{Cons}: It requires the user of a \texttt{variant} to account for the
null state everywhere. This is a major disadvantage of a pointer that have
been referred to by Tony Hoare as \cite{NullRef}. References were introduced
as a solution to provide non-null semantics for a pointer. While it is possible
to provide a separate class template which is analogous to a reference,
it would be preferred to introduce non-null semantics by default.
Since opting in for the null state given non-null semantics is trivial,
while the converse is not.

\subsubsection{Valid, but Unspecified State}
A state in which the \texttt{variant} has none of its alternatives constructed, but the
discriminator of the \texttt{variant} is in a specified state. This state was introduced
at WG21's 2015 Lenexa meeting, and is the approach taken by \cite{N4542}.

This state is visible via the \texttt{bool}-returning function \texttt{valid()}.
The function is named \texttt{valid()} because even though the \texttt{variant} is
technically in a valid state, for all intents and purposes it is invalid.
It may be worth considering alternative names in order to avoid confusion
(e.g. \texttt{operator bool}, \texttt{unspecified}, \texttt{usable}, \texttt{ready}).

\textbf{Exception Safety}: Basic

\textbf{Pros}: It handles all types including ones that can throw during move construction,
and it does not incur any performance overhead. The null state is opt-in,
so there is no null state by default.

\textbf{Cons}: Since this state is visible and partially well-defined, it's perfectly
valid for users to call the \texttt{valid()} function anywhere in the code to test for
the valid, but unspecified state. This is contrary to its intended use, which is
to check for the validity of the \texttt{variant} within a \texttt{catch} clause.
The following are somewhat contrived examples of intended and unintended use cases.

\begin{lstlisting}[language=cpp]
// intended usage:
void F(variant<T, U>& v, const variant<T, U>& w) {
  try {
    v = w;
  } catch (const std::exception& ex) {
    if (!v.valid()) {
      // Failed during in-place construction, old value is unknown.
    } else {
      // Failed during temporary construction, old value is in `v`.
    }
  }
}
\end{lstlisting}

\begin{lstlisting}[language=cpp]
// intended usage:
void G(variant<T, U>& v, const variant<T, U>& w) {
  // Well, even if I was to catch the exception, I can't do anything about it.
  // So... just propagate it!
  v = w;
}

void H(variant<T, U>& v, const variant<T, U>& w) {
  try {
    G(v, w);
  } catch (const std::exception& ex) {
    if (!v.valid()) {
      // Failed during in-place construction, old value is unknown.
    } else {
      // Failed during temporary construction, old value is in `v`.
    }
  }
}
\end{lstlisting}

\begin{lstlisting}[language=cpp]
// unintended, valid usage:
void F(variant<T, U> v) {
  assert(v.valid());
  // Ok, use v.
}
\end{lstlisting}

\begin{lstlisting}[language=cpp]
// unintended, valid usage:
void F(const variant<T, U>& v) {
  assert(v.valid());
  // Ok, use v.
}
\end{lstlisting}

\begin{lstlisting}[language=cpp]
// unintended, valid usage:
void F(variant<T, U>& v) {
  if (!v.valid()) {
    // Make v valid.
    v = T{};
  }
  // Ok, use v.
}
\end{lstlisting}

Ideally, we should eliminate the unintended usage of the \texttt{valid()} function.

{\color{solarized@blue}
\subsubsection{Indeterminate State}
\label{indeterminate}}
A state in which the \texttt{variant} has none of its alternatives constructed, and the
discriminator of the \texttt{variant} is also in an unspecified state. The only valid
operations in this state are: assignment (e.g. \texttt{operator=}, \texttt{emplace}),
and destruction. Any other operations performed in this state have undefined behavior.

\textbf{Exception Safety}: None

\textbf{Pros}: It handles all types including ones that can throw during move construction,
and it does not incur any performance overhead. The null state is opt-in,
so there is no null state by default.

Unlike the valid, but unspecified state, this state is unobservable, and any
operations aside from assignment and destruction trigger undefined behavior.
With these properties, a function can and is required to make stronger
assumptions about the state of a \texttt{variant}.

\begin{lstlisting}[language=cpp]
void F(variant<T, U> v) {
  // v must be valid.
}
\end{lstlisting}

\begin{lstlisting}[language=cpp]
void F(const variant<T, U>& v) {
  // Assume v is valid.
}
\end{lstlisting}

\begin{lstlisting}[language=cpp]
void F(variant<T, U>& v) {
  // Either:
  //   - Assume v is valid, read and/or mutate the value, OR
  //   - Assume v is in an indeterminate state and assign a value to it.
}
\end{lstlisting}

Note that the above conditions are exactly what we would and be required to assume
if we were to replace \texttt{variant<T, U>} with \texttt{int}.

\textbf{Cons}: Since all other operations aside from assignment and destruction trigger
undefined behavior, this state is more dangerous than the valid, but unspecified
state. This also means that under the conditions in which an exception is thrown
during \texttt{variant} assignment, we provide no exception safety guarantees.

\subsection{Default Construction}
Many have claimed desirable for a \texttt{variant} to be default constructible for ease
of use in containers such as \texttt{std::vector}, \texttt{std::map}, and
\texttt{std::array}. The requirements of a default constructor for
\texttt{std::vector} and \texttt{std::map} are not as strong, as there are
alternative constructors and functions available to better support types
without a default constructor. For example, \texttt{std::vector} provides
\texttt{std::vector::vector(size\_t count, const T\&)} which can be used
instead of \texttt{std::vector::vector(size\_t count)}, and \texttt{std::map}
provides \texttt{std::map::insert} which can be used instead of
\texttt{std::map::operator[]}. While there are alternative approaches, it is
indeed more difficult to use, as most users would prefer \texttt{m[key] =
value;} over \texttt{m.insert(std::make\_pair(key, value));}

For \texttt{std::array}, there are no good alternatives. One would usually
resort to using \texttt{std::vector} instead which may be undesirable due to the
incurred dynamic allocation and the loss of fixed size guarantee.

This section discusses various default constructed states. The default
constructed state proposed in this paper is mentioned last, highlighted in
{\color{solarized@blue}blue}.

\subsubsection{First Type}
\label{firsttype}
This is the design that LEWG opted for at the WG21's 2015 Lenexa meeting. This is the
behavior of a \texttt{union} when value initialized, and it makes sense for a
\texttt{variant} if the assumption is that it should be modeled after
\texttt{union}.

\textbf{Pros}: This is what makes the most sense if we \textbf{had to} default construct
one of the types, and this state initializes to a fully valid state.

\textbf{Cons}:

\begin{itemize}
  \item \texttt{variant} remains non-default-constructible if the first type is
    non-default-constructible.
  \item The exception-safety guarantee depends on the first type.
  \item The runtime complexity guarantee depends on the first type.
  \item The behavior of default construction of \texttt{variant} changes based
    on the \textit{order} of types.
\end{itemize}

Some have argued that the varying behavior of default construction across different
instantiations of \texttt{variant} should not be surprising since
\texttt{variant<T, U>} and \texttt{variant<U, T>} are separate types as far as
the language is concerned. However, consider that \texttt{vector<bool>} and
\texttt{vector<int>} are also separate types as far as the language is concerned
and the amount of pain that comes from the inconsistent interfaces and behavior.
Even though they are indeed separate types, there is still an intuitive
expectation that such a class template has consistent behavior across
instantiations with different types.

\subsubsection{Valid, but Unspecified State}
\label{defaultvbus}
\cite{N4542} mentions that LEWG has opted against default constructing into
a valid, but unspecified state in order to limit the paths of getting into such
a state to the exceptional cases.

\textbf{Pros}: Under the assumption that default construction of \texttt{variant}
is desirable, it would be desirable for \textbf{any} \texttt{variant} to be
default constructible. Default constructing into the valid, but unspecified state
is one option that allows any \texttt{variant} to be default constructible
regardless of the types it contains.

By default constructing into this state, the behavior of default construction stays
consistent for any \texttt{variant}, provides the \texttt{noexcept} guarantee,
and constant runtime complexity guarantee.

\textbf{Cons}: As discussed in \fullref{emptyvbus}, recall that a
valid, but unspecified state is visible. As such, default constructing into this
state would make it a common state that users can and would be required to check
for outside of the \texttt{catch} clause. That is, the following code becomes
perfectly valid:

\begin{lstlisting}[language=cpp]
void F(variant<T, U>& v) {
  if (!v.valid()) {
    // Make v valid.
    v = T{};
  }
  // Ok, use v.
}

int main() {
  variant<T, U> v;
  F(v);
}
\end{lstlisting}

In order to avoid such code, the user would have to add the "\texttt{v.valid()} is
\texttt{true}" precondition to function \texttt{F}. Naturally, this precondition
would exist for all operations of \texttt{variant} except assignment
(e.g. \texttt{operator=}, \texttt{emplace}), destruction, observation (e.g.
\texttt{index}, \texttt{valid}), and copy and move construction. This design would
only be slightly better than requiring the null state to always exist, or deferring
to using \texttt{std::optional<variant<Types...>{}>}.

{\color{solarized@blue}\subsubsection{Indeterminate State}}
\textbf{Pros}: Refer to \fullref{indeterminate} and \fullref{defaultvbus} for
previous discussions regarding the advantages of having this kind of state.

Unlike the valid, but unspecified state, the only valid operations of this state are
assignment (e.g. \texttt{operator=}, \texttt{emplace}), and destruction. As mentioned
in \fullref{indeterminate}, this means that functions can make stronger assumptions about
the state of a \texttt{variant} object.

Note that this behavior is similar how \texttt{int} behaves:

\begin{lstlisting}[language=cpp]
int x;  // uninitialized
x = 42;  // assign
\end{lstlisting}

\begin{lstlisting}[language=cpp]
std::variant<int, std::string> v;  // indeterminate
v = 42;  // assign
\end{lstlisting}

The argument is that validity checks of a \texttt{variant} are no longer necessary nor
possible, the same way validity checks of an \texttt{int} are not necessary nor possible.
It is required that a \texttt{variant} object in an indeterminate state be assigned a
value before use, the same way it is required that uninitialized \texttt{int} be assigned
a value before use, in order to avoid undefined behavior.

This is true for \texttt{enum} as well, which is an existing discriminated union with
value semantics.

\begin{lstlisting}[language=cpp]
enum class Color { Blue, Green, Red };
Color color;  // uninitialized
color = Color::Blue;  // assigned
\end{lstlisting}

Another argument is one of efficiency. Given a size \texttt{N}, the following are
different ways to initialize a \texttt{std::array<int, N>}, and
\texttt{std::vector<int>} of size \texttt{N}:

\begin{lstlisting}[language=cpp]
std::array<int, N> v;  // uninitialized

std::array<int, N> v = {};  // initialized to 0
\end{lstlisting}

\begin{lstlisting}[language=cpp]
// avoid initialization of N integers
std::vector<int> v;
v.reserve(N);

// initialized to 0
std::vector<int> v(N);
\end{lstlisting}

It's common practice to avoid the cost of initialization for performance gains.
The argument here is that if there are performance gains from not
initializing \texttt{int} to \texttt{0}, there must also be performance gains
from not default constructing the first type of \texttt{variant}.

This design has the following properties:

\begin{itemize}
  \item Any \texttt{variant<Types...>} is default constructible.
  \item Consistent behavior of default construction for all
    \texttt{variant<Types...>}.
  \item \texttt{noexcept} exception-safety guarantee.
  \item Constant runtime complexity guarantee.
\end{itemize}

\textbf{Cons}: While the behavior of this state is \textbf{similar} to \texttt{int},
it's not \textbf{equivalent} due to the fact that classes cannot differentiate
between default initialization and value initialization.

\begin{lstlisting}[language=cpp]
int x;  // uninitialized
int y{};  // initialized to 0
\end{lstlisting}

\begin{lstlisting}[language=cpp]
std::variant<int, std::string> v;  // indeterminate
std::variant<int, std::string> w{};  // indeterminate
\end{lstlisting}

It should however be noted that this caveat already exist for atomic types in
the \texttt{<atomic>} library.

\begin{lstlisting}[language=cpp]
std::atomic<int> x;  // uninitialized
std::atomic<int> y{};  // uninitialized
\end{lstlisting}

Lastly, it goes against one of the guidelines given in the \cite{CCG}:
\textbf{ES.20: Always initialize an object} which recommends to avoid
uninitialized state.

\subsection{Null State}
This section discusses the approaches in which the null state could be handled
for \texttt{variant}. The strategy proposed in this paper is mentioned first, highlighted
in {\color{solarized@blue}blue}.

{\color{solarized@blue}\subsubsection{\texttt{std::nullvar\_t}}}
This approach is to simply introduce an empty class type
\texttt{std::nullvar\_t} analogous to \texttt{std::nullopt\_t}. Users would opt-in for
a null state by specifying \texttt{std::nullvar\_t} as one of the alternatives.

Furthermore, \texttt{variant} does not provide special behavior for
\texttt{std::nullvar\_t}. The main motivation is to keep consistent behavior of
\texttt{variant<Types...>}. As mentioned in \fullref{firsttype}, there is an expectation that
a class template has consistent behavior across instantiations with different types.
This follows that design principle of not introducing special behavior due to involvement
of a type that we consider special. This, in turn, facilitates generic programming.

\begin{itemize}
  \item The types that need to be handled for visitation all appear in the type list of
    a \texttt{variant}.
  \item Consistent relationship between
    \begin{itemize}
      \item (\texttt{std::nullvar\_t}, \texttt{std::variant})
      \item (\texttt{std::nullopt\_t}, \texttt{std::optional})
      \item (\texttt{std::nullptr\_t}, \texttt{T*})
    \end{itemize}
  \item Since there is no special behavior provided for \texttt{std::nullvar\_t},
    users are free to provide a custom type that represents the null state within
    their project. (e.g. \texttt{empty\_t} in Adobe ASL, \texttt{none\_t} in Boost,
    \texttt{None} in Facebook Folly, \texttt{Nothing} in Apache Mesos)
\end{itemize}

Consider the symmetry in the handlers of a generalized \texttt{type\_switch} where
types such as pointers and \texttt{std::optional} are supported:

\begin{lstlisting}[language=cpp]
std::optional<std::size_t> x;
std::variant<int, std::string, std::nullvar_t> y;
int *z;
/* ... */
std::type_switch (x, y, z) (
  [](std::size_t   , int                 , int           ) { /* ... */ },
  [](std::size_t   , int                 , std::nullptr_t) { /* ... */ },
  [](std::size_t   , const std::string&  , int           ) { /* ... */ },
  [](std::size_t   , const std::string&  , std::nullptr_t) { /* ... */ },
  [](std::size_t   , std::nullvar_t      , int           ) { /* ... */ },
  [](std::size_t   , std::nullvar_t      , std::nullptr_t) { /* ... */ },
  [](std::nullopt_t, int                 , int           ) { /* ... */ },
  [](std::nullopt_t, int                 , std::nullptr_t) { /* ... */ },
  [](std::nullopt_t, const std::string&  , int           ) { /* ... */ },
  [](std::nullopt_t, const std::string&  , std::nullptr_t) { /* ... */ },
  [](std::nullopt_t, std::nullvar_t      , int           ) { /* ... */ },
  [](std::nullopt_t, std::nullvar_t      , std::nullptr_t) { /* ... */ }
);
\end{lstlisting}

\subsubsection{\texttt{std::optional<std::variant<Types...>{}>}}
\label{ov}
This is an intuitive approach since \texttt{std::optional} exists to provide the
notion of a null state. Wrapping the \texttt{variant} inside of an
\texttt{optional} would augment the null state to a list of types
\texttt{Types...} as desired. However, this introduces an extra level of
indirection that needs to be observed and dereferenced. This matters because
generally flat control flow is more readable and easier to reason about compared
to nested control flow. Consider the following control flow with
\texttt{std::optional<std::variant<int, std::string>{}>}:

\begin{lstlisting}[language=cpp]
std::optional<std::variant<int, std::string>> x, y;
/* ... */
if (x && y) {
  std::type_switch (*x, *y) (
    [](int, int) { /* handle int, int. */ },
    [](int, const std::string&) { /* handle int, string. */ },
    [](const std::string&, int) { /* handle string, int. */ },
    [](const std::string&, const std::string&) { /* handle string, string. */ }
  );
} else if (x) {
  std::type_switch (x) (
    [](int) { /* handle int, null. */ },
    [](const std::string&) { /* handle string, null. */ },
  );
} else if (y) {
  std::type_switch (y) (
    [](int) { /* handle null, int. */ },
    [](const std::string&) { /* handle null, string. */ },
  );
} else {
  /* handle null, null */
}
\end{lstlisting}

Compared to the control flow with
\texttt{std::variant<int, std::string, std::nullvar\_t>}:

\begin{lstlisting}[language=cpp]
std::variant<int, std::string, std::nullvar_t> x, y;
/* ... */
std::type_switch (x, y) (
  // no need for comments, the signature tells you exactly what types are being handled.
  [](int               , int               ) { /* ... */ },
  [](int               , const std::string&) { /* ... */ },
  [](int               , std::nullvar_t    ) { /* ... */ },
  [](const std::string&, int               ) { /* ... */ },
  [](const std::string&, const std::string&) { /* ... */ },
  [](const std::string&, std::nullvar_t    ) { /* ... */ },
  [](std::nullvar_t    , int               ) { /* ... */ },
  [](std::nullvar_t    , const std::string&) { /* ... */ },
  [](std::nullvar_t    , std::nullvar_t    ) { /* ... */ }
);
\end{lstlisting}

We can see that \texttt{std::variant<int, std::string, std::nullvar\_t>} enables a flatter
control flow compared to \texttt{std::optional<std::variant<int, std::string>{}>}.

\subsubsection{Separate Class Template: \texttt{std::nullable\_variant}}
The idea is to introduce a separate class template to represent a nullable
\texttt{variant}, similar to the way pointer and reference are distinct type
modifiers. However, given that a \texttt{variant} is a discriminated union,
it seems more natural that this case be generically handled where a null state
is simply one of the states of the discriminated union.

The main advantage of introducing this class template would be that an empty
state of any kind (e.g. valid, but unspecified, indeterminate) need not exist.

There are at least 2 possible interfaces:

\begin{enumerate}
  \item Essentially an alias for \texttt{std::optional<std::variant<Types...>{}>}
  \item Modified behavior based on \texttt{std::variant<std::nullvar\_t, Types...>}
\end{enumerate}

The disadvantages of (1) are discussed in \fullref{ov}.

For (2) the main disadvantages are:

\begin{itemize}
  \item \texttt{std::nullvar\_t} becomes special which disallows the use of a
    custom null type.
  \item Either \texttt{std::nullvar\_t} is disallowed for \texttt{variant}, or
    users need to be aware of the subtle differences between
    \texttt{variant<std::nullvar\_t, Types...>} vs
    \texttt{nullable\_variant<Types...>}.
  \item In generic programming, it would be required to handle \texttt{variant} and
    \texttt{nullable\_variant} separately even in cases where it can be handled generically.
\end{itemize}

\subsection{Discriminator}
This section discusses the possible discriminator to refer to an alternative of
a \texttt{variant}. The strategy proposed in this paper is mentioned last,
highlighted in {\color{solarized@blue}blue}.

\subsubsection{Name}
When identifiers are used to distinguish the members of a discriminated union,
it is a sum type. This approach is used by \texttt{union} for example, where each member
of a \texttt{union} has an associated identifier. Given
\texttt{union \{ T t; U u; \};}, \texttt{x} and \texttt{y} are distinct because
the identifier is the discriminator.
Since there are no identifiers involved in \texttt{variant<T, U>}, in order to support
this feature, \texttt{variant} would need to be introduced at the language-level rather
than at the library-level.

\subsubsection{Type}
This approach uses the type of the alternatives as the discriminator of a discriminated union.

\textbf{Pros}: Since arbitrary new types can be created with unique names, this
enforces that every alternative be uniquely identified by a type which maintains
the reference relationship even in the event of reordering. For example, given
\texttt{variant<Circle, Square, Triangle> shape;} \texttt{get<Circle>(shape);}
retrieves \texttt{Circle} even if we change the declaration of the shape
variable to \texttt{variant<Square, Triangle, Circle> shape;}

Furthermore, the inability to represent multiple occurrences of a single type
\texttt{T} as distinct states can be addressed by introducing wrapper classes
\texttt{X} and \texttt{Y} where each of them wrap an instance of \texttt{T}.
This is useful also because it introduces a name that is distinctive at the type-level
(unlike type alias declarations).

Lastly, The \texttt{variant} interface becomes simpler since there is no need to
support index-based operations such as \texttt{variant(in\_place<0>, 42)} and
\texttt{get<0>(v)}.

\textbf{Cons}: The notion of a named discriminator and the corresponding type
are conflated into a single type. It also leads to the question: should multiple
occurrences of a single type \texttt{T} in \texttt{Types...} (e.g.
\texttt{variant<T, T>}) be disallowed, or allowed, but do not represent distinct states?

Neither of these definitions are accurate in terms of a discriminated union from
set theory nor sum type from type theory. Therefore, this approach is more
suitable to be considered a workaround technique to emulate a sum type, rather
than being part of library design.

{\color{solarized@blue}\subsubsection{Index}}

This approach uses the index of an alternative as the discriminator. This behavior of
implicitly assigned indices is consistent with \texttt{std::tuple}, where the elements of
\texttt{std::tuple} can be referred to with its their indices, or by their type if the
type is unique within \texttt{Types...}.

\textbf{Pros}: This definition is accurate to the definition of discriminated union,
and the interface is consistent with \texttt{std::tuple}. The workaround technique of
introducing new types and using the type-based operations are still applicable.

\textbf{Cons}: While using the indices may seem essentially equivalent to using associated
names, a significant difference is that the \textit{order} of types become
sensitive in the index-based operations. Suppose the type of \texttt{v} in the
expression \texttt{get<0>(v);} is \texttt{variant<T, U>}. If the type is later
changed to \texttt{variant<U, T>}, or \texttt{variant<V, T, U>}, a different member is
retrieved.

This is contrary to using the name as the discriminator. Consider \texttt{union}
as the example of name being used as the discriminator (except union does not keep track
of the discriminator itself). Regardless of whether the type of \texttt{u} in the
expression \texttt{u.x} is \texttt{union \{ X x; Y y; \};} or
\texttt{union \{ Y y; X x; \};}, the member of type \texttt{X} is retrieved.

This is an inherent difference in the meaning of the expressions \texttt{get<0>(v)} and
\texttt{u.x}, the former says "get me whatever is the first alternative" whereas the
latter says "get me the alternative that is tagged with \texttt{x}".

\subsection{Visitation: Interface}
This section describes a possible visitation mechanism and does not preclude other
mechanisms. For example, \cite{P0050} is a draft of a pattern matching proposal at the
library-level, while \cite{Mach7} is an experimental library solution to
\cite{N3449} which aims to bring pattern matching at the language-level.
The mechanism being proposed here is a type switch which is much simpler than
generalized pattern matching, and only specifies the aspects involving
\texttt{variant}.

\subsubsection{\texttt{visit(F, Variants...);}}

\cite{N3915} proposed \texttt{apply} which takes a function object \texttt{F}
and a tuple \texttt{Tuple}, and dispatches \texttt{F} with the elements of
\texttt{Tuple}. This function is similar, but for \texttt{variant}. That is,
\texttt{visit} takes a function object \texttt{F} and \texttt{Variants...}, and
dispatches \texttt{F} with the content of each the \texttt{Variants...}.

Although the similarity to \texttt{apply} seem desirable for consistency, I
believe there are major drawbacks at the callsite. The inherent difference
between \texttt{apply} and \texttt{visit} is that \texttt{apply} only requires a
single handler that handles the elements of the \texttt{tuple}, whereas
\texttt{visit} (almost always) requires many handlers that handle the
cartesian product of the alternatives of the \texttt{variant} objects.

Consider a few sample usages of visiting a \texttt{variant<int, std::string>}
The following are 3 of the possible ways to provide the handlers via the
\texttt{visit} interface.

\begin{itemize}
  \item Function object which requires out-of-line definition.
  \item Generic lambda to provide a single generic handler inline.
  \item \texttt{overload} to provide specific handlers inline.  // P0051
\end{itemize}

\begin{lstlisting}[language=cpp]
int main() {
  std::variant<int, std::string> v(42);

  // Function object which requires out-of-line definition.
  struct Print {
    void operator()(int value) const { std::cout << "int: " << value; }
    void operator()(const std::string& value) const { std::cout << "string: " << value; }
  };
  std::visit(Print{}, v);

  // Generic lambda to provide a generic handler inline.
  std::visit([](const auto& value) { std::cout << value; }, v);

  // `overload` to provide specific handlers inline.  // P0051
  std::visit(
    overload([](int value) { std::cout << "int: " << value; }
             [](const std::string& value) { std::cout << "string: " << value; }),
    v);
}
\end{lstlisting}

{\color{solarized@blue}\subsubsection{\texttt{type\_switch(Variants...)(Fs...);}}}
The type switch mechanism here is similar to \texttt{visit}, but there are a couple
of differences.

\begin{itemize}
  \item The \texttt{variant} objects come before the handlers.
  \item \texttt{overload} is no longer necessary.
\end{itemize}

\begin{lstlisting}[language=cpp]
int main() {
  std::variant<int, std::string> v(42);

  // Function objects can still be defined out-of-line.
  struct Print {
    void operator()(int value) const { std::cout << "int: " << value; }
    void operator()(const std::string& value) const { std::cout << "string: " << value; }
  };
  std::type_switch (v) ( Print{} );

  // Generic lambda to provide a generic handler inline.
  std::type_switch (v) ( [](const auto& value) { std::cout << value; } );

  // No need for `overload`.
  std::type_switch (v) (
    [](int value) { std::cout << "int: " << value; },
    [](const std::string& value) { std::cout << "string: " << value; }
  );
}
\end{lstlisting}

This approach is favored over the \texttt{visit} function considering the inherent
difference that \texttt{variant} visitation require multiple handlers in
overwhelming number of cases. It is also more reminiscent of existing language
constructs such as the \texttt{switch} statement in C++ and various forms of
\texttt{match} statements in functional languages such as OCaml.
The name \texttt{type\_switch} was chosen over \texttt{match} to

\begin{itemize}
  \item leave \texttt{match} available for language-level pattern matching
  \item avoid potential confusion with the \texttt{match}-related names in
    the \texttt{<regex>} library.
\end{itemize}

\subsection{Visitation: Return Type}
This section explores various options regarding the return type of visitation.
Should the return type be deduced to something sensible? or should it be
required that all of the handlers return the same type?

Consider the following example:

\begin{lstlisting}[language=cpp]
std::variant<int, std::string> v(42);
auto result = std::type_switch (v) (
  [](int value) /* -> int */ { return value; },
  [](const std::string& value) /* -> std::size_t */ { return value.size(); }
);
// What is the result of decltype(result)? Does this even compile?
\end{lstlisting}

\subsubsection{\texttt{std::common\_type\_t<return\_types...>}}
The approach here is to deduce the final return type as the common type of
return types of each of the handlers. While this approach may seem reasonable,
it is quite dangerous as we can very easily have loss of data and/or precision.
For example, the deduced return type of the example above would be
\texttt{std::size\_t} which is likely to be a silent error if the \texttt{int}
handler returns a negative value.

\subsubsection{\texttt{std::variant<return\_types...>}}
In order to prevent data loss and type information, we could try to deduce the
return type to be \texttt{std::variant<return\_types...>}. In the case of the above
example, the return type would be \texttt{std::variant<int, std::size\_t>}.

The immediately obvious disadvantage of this approach is that even if all return
types are \texttt{T}, the final return type is \texttt{variant<T>} if duplicates removed,
or \texttt{variant<T, T, ..., T>} otherwise, rather than \texttt{T}.
While this can be mitigated by adding it as a special rule, it immediately starts
to add complexity to the return type deduction rule for a \texttt{variant}.

Another case to keep in mind is the presence of \texttt{void}-returning functions.
Consider a function object where the return types of \texttt{operator()} are:
\texttt{int, std::string, void}. Since \texttt{void} does not add additional state
to a variant, naively deducing the return type to be
\texttt{variant<int, std::string, void>} is not sufficient. The actual deduced
return type needs to be \texttt{variant<int, std::string, std::nullvar\_t>}.

Other situations that may or may not require special rules:

\begin{itemize}
  \item Two handlers with return types: \texttt{const X\&} and \texttt{const Y\&}.
    Should the deduced return type be \texttt{variant<const X\&, const Y\&>}, or
    \texttt{const variant<X, Y>\&}?
  \item Two handlers with return types: \texttt{const D1*} and \texttt{const D2*},
    and \texttt{D1} and \texttt{D2} both inherit from \texttt{B}. Should the return
    type be \texttt{variant<const D1*, const D2*>}, or should the covariant return
    type rule kick in and therefore result in \texttt{const B*}?
\end{itemize}

Return type deduction rules in C++ are already quite complex at the
language-level today. Introducing this level of complexity at the library-level
would be very much undesirable.

{\color{solarized@blue}\subsubsection{Same Type}}

Having considered the disadvantages of the two approaches above, this paper proposes that
the return types of all of the handlers must have the same return type. This rule enforces
the programmer to be explicit, does not suffer from loss of data/type, and is simple to
remember.

In order to mitigate the need to repeatedly specify the final return type in each handler,
an explicit return type can be specified as a template argument to \texttt{type\_switch}.

\begin{lstlisting}[language=cpp]
std::variant<int, std::string> v(42);
auto result = std::type_switch<variant<int, std::size_t>>(v) (
  [](int value) { return value; },
  [](const std::string& value) { return value.size(); }
);
// decltype(result) == variant<int, std::size_t>
\end{lstlisting}

\subsection{Visitation: Dispatch}
This section describes how dispatching works for visitation of \texttt{variant} objects.
The visitation mechanism proposed here requires exhaustive match, but again,
it does not preclude other proposals to override or augment this proposal.

The handler can have a superset of all possible cases, the only requirement is that
it covers all potential cases of the match. For example, consider the following code:

\begin{lstlisting}[language=cpp]
class Circle;
class Square;
class Rectangle;
class Rhombus;
class RightTriangle;
class EquilateralTriangle;

using Shape = variant<Circle, Square, Rectangle, Rhombus, RightTriangle, AcuteTriangle>;
using Quadrilateral = variant<Square, Rectangle, Rhombus>;
using Triangle = variant<RightTriangle, AcuteTriangle>;

// `get_area` can handle all of `Shape`, `Quadrilateral`, and `Triangle`.
template <class... Types>
double get_area(const std::variant<Types...>& shape) {
  return type_switch (shape) (
    [](const Circle& that) { /* ... */ },
    [](const Square& that) { /* ... */ },
    [](const Rectangle& that) { /* ... */ },
    [](const Rhombus& that) { /* ... */ },
    [](const RightTriangle& that) { /* ... */ },
    [](const EquilateralTriangle& that) { /* ... */ }
  );
}
\end{lstlisting}

\subsubsection{Unique Alternatives}
When the alternatives consist of unique types, we simply provide handlers for
each alternative.

\subsubsection{Duplicate Alternatives}
When there are duplicate alternative types, it gets a bit more complicated.

The following code is allowed:

\begin{lstlisting}[language=cpp]
variant<int, int, std::string> v;
/* ... */
type_switch (v) (
  [](int) { /* handles both int alternatives. */ },
  [](const std::string&) { /* handles string. */ }
);
\end{lstlisting}

This may seem crazy at first, but consider a common use case of the default
handler that matches anything with \texttt{auto\&\&}, as well as the use of
constrained function templates with SFINAE or Concepts to match a family
of types.

\begin{lstlisting}[language=cpp]
variant<int, std::size_t, double, std::string> v;

/* ... */

// Matching multiple types with a single default handler:
type_switch (v) (
  [](int) { /* handle int. */
  [](auto&&) { /* handles int, std::size_t and string. */ },
);

// Matching subset of types with constrained function templates.
struct handler {
  template <typename T>
  std::enable_if<std::is_integral_v<T>> operator()(T) const {
    /* handles int, and std::size_t */
  }

  void operator()(double) const { /* handle double */ }
  void operator()(const std::string&) const { /* handle string */ }
};

type_switch (v) ( handler{} );
\end{lstlisting}

The expectation is that a handler is expected to generically handle whatever type it matches,
and this is consistent even in the presence of duplicate types.

In the rare cases where it is useful to know the original type in which the value
came from, an index-aware handler can be provided to retrieve the indices of the
originating types. This situation can arise from duplicate types, but also from
the consequence of allowing references.

\begin{lstlisting}[language=cpp]
int x = 42;
variant<int, int&> v(in_place<1>, x);
type_switch (v) ( [](int&) { /* matches both int, and int& */ );

// index-aware handler
struct index_aware {
  template <size_t I>
  void operator()(int&) const {
    /* still matches both int, and int&, but `I` tells you which one. */
  }
};

type_switch (v) ( index_aware{} );
\end{lstlisting}

Since non-deduced template parameters cannot be specified in a lambda, the
implication here is that an index aware handler must be defined as an
out-of-line function object. However, considering that this is likely a
rare use case, it is unlikely to be a big deal.

\subsection{Miscellaneous}

\subsubsection{\texttt{constexpr}}
This proposal stays consistent with \texttt{std::optional} in terms of its
\texttt{constexpr}-ness. More sophisticated conditions such as
\texttt{std::is\_trivially\_copy\_constructible\_v} to increase the
\texttt{constexpr}-ness is not considered in this proposal.

\subsubsection{\texttt{void}}
\texttt{void} is allowed, and adds no state. This result follows from the fact that
the proposed \texttt{variant} design accurately models the formal definition of a
discriminated union. Since the \texttt{void} type has an empty set of values (i.e. 0
states), it has a + 0 effect on the number of states of a \texttt{variant} object.

While this is a theoretical argument, the practical argument is that it is not
possible to use \texttt{void} as a match type for multi-visitation. Consider a single
visitation scenario where \texttt{void} is used to indicate the null state.

\begin{lstlisting}[language=cpp]
variant<int, void> v;
/* ... */
type_switch (v) (
  [](int ) { /* ... */ },
  [](void) { /* ... */ }  // == []() { /* ... */ }
);
\end{lstlisting}

Now imagine generalizing that to multi-visitation:

\begin{lstlisting}[language=cpp]
variant<int, void> v, w;
/* ... */
type_switch (v, w) (
  [](int , int)  { /* ... */ },
  [](int , void) { /* ... */ },  // invalid
  [](void, int)  { /* ... */ },  // invalid
  [](void, void) { /* ... */ }   // invalid
);
\end{lstlisting}

Therefore even for practical reasons, there is clear benefit to introducing a
\texttt{std::nullvar\_t}.

\subsubsection{References}
References are allowed as an alternative.

\section{Extensibility}

This section exists to demonstrate how this \texttt{variant} design can be extended to
support various features desired by polarizing groups. It is intentionally
separated out from \fullref{designdecisions}, since extensibility in itself was
not a driving factor in the proposed design. However, it is evident that starting
from the proposed design, those who want different semantics can extend it to get
the semantics they want, whereas trying to arrive at this design based on other
alternatives would be much more difficult.

\subsection{Disallow Default Construction}
Given a \texttt{variant} that deletes the default constructor, it would be very
difficult to extend that \texttt{variant} and make it default constructible.
However, the converse is trivial.

\begin{lstlisting}[language=cpp]
template <class... Types>
class Variant : public std::variant<Types...> {
public:
  Variant() = delete;
};
\end{lstlisting}

\subsection{Default Construct the First Type}
Given a \texttt{variant} that default constructs to the first type,
it would be very difficult to extend that \texttt{variant} and keep it
uninitialized. However, the converse is trivial.

\begin{lstlisting}[language=cpp]
template <class Head, class... Tail>
class Variant : public std::variant<Head, Tail...> {
public:
  Variant() : std::variant<Head, Tail...>(Head{}) {}
};
\end{lstlisting}

\subsection{Turn off Assignment}
\label{turnoffassignment}
Given a \texttt{variant} that has assignment turned off, users who want assignment would
need to implement their own. However, the converse scenario of turning off given
functionality is very easy.

\begin{lstlisting}[language=cpp]
template <class... Types>
class NonAssignableVariant : public std::variant<Types...> {
public:
  template <std::size_t I, class... Args> void emplace(Args&&...) = delete;

  template <std::size_t I, class U, class... Args>
  void emplace(std::initializer_list<U>, Args&&...) = delete;

  template <class T, class... Args> void emplace(Args&&...) = delete;

  template <class T, class U, class... Args>
  void emplace(std::initializer_list<U>, Args&&...) = delete;

  template <class U> variant& operator=(U&&) = delete;

  variant& operator=(const variant&) = delete;
  variant& operator=(variant&&) = delete;
};
\end{lstlisting}

\subsection{Turn off Assignment under Certain Conditions}
Given a \texttt{variant} where assignment is turned off in some cases, users who want
assignment even in those cases would need to override the behavior with their
own implementation of assignment. Leveraging \fullref{turnoffassignment},
the converse scenario remains very simple.

\begin{lstlisting}[language=cpp]
template <class... Types>
class Variant
    : public std::conditional_t<
          (std::is_nothrow_move_constructible_v<Types> && ...),
          std::variant<Types...>,
          NonAssignableVariant<Types...>> {};
\end{lstlisting}

\subsection{Nullable Variant}
Given a \texttt{variant} that always carries a null state and default constructs
into it as well as recovering to that state when an exception occurs during the
move construction of assignment, it would be difficult to make a non-nullable
variant out of it without adding runtime checks. Admittedly, augmenting the
null state to a non-null \texttt{variant} and providing augmented behavior was
not as trivial as I thought it would be, but it's still doable.

\begin{lstlisting}[language=cpp]
template <class... Types>
class Variant : public std::variant<std::nullvar_t, Types...> {
public:
  using super = std::variant<std::nullvar_t, Types...>;

  Variant() : super(std::nullvar) {}

  template <std::size_t I, class... Args>
  void emplace(Args&&... args) {
    try_([&] { super::template emplace<I>(std::forward<Args>(args)...); });
  }

  template <size_t I, class U, class... Args>
  auto emplace(std::initializer_list<U> init, Args&&... args)
      -> decltype(super::template emplace<I>(init, std::forward<Args>(args)...)) {
    try_([&] { super::template emplace<I>(init, std::forward<Args>(args)...); });
  }

  template <class T, class... Args>
  void emplace(Args&&... args) {
    try_([&] { super::template emplace<T>(std::forward<Args>(args)...); });
  }

  template <class T, class U, class... Args>
  auto emplace(std::initializer_list<U> init, Args&&... args)
      -> decltype(super::template emplace<T>(init, std::forward<Args>(args)...)) {
    try_([&] { super::template emplace<T>(init, std::forward<Args>(args)...); });
  }

  template <class U>
  auto operator=(U&& u) -> decltype(super::operator=(std::forward<U>(u)), *this) {
    try_([&] { super::operator=(std::forward<U>(u)); });
    return *this;
  }

  Variant& operator=(const Variant& that) {
    try_([&] { super::operator=(that); });
    return *this;
  }

  Variant& operator=(Variant&& that) noexcept(noexcept(super::operator=(std::move(that)))) {
    try_([&] { super::operator=(std::move(that)); });
    return *this;
  }

private:
  template <class F>
  void try_(F&& f) {
    try {
      std::forward<F>(f)();
    } catch (const std::bad_variant_assign& ex) {
      *this = std::nullvar;
      ex.rethrow_nested();
    }
  }
};
\end{lstlisting}

\subsection{Double Storage}
Using double storage to achieve strong exception safety guarantee may be a
tradeoff that many people are willing to make. For those users, we can augment
the proposed \texttt{variant} with another storage and implement the double
storage mechanism. Again, the converse scenario would be much more difficult
since there is no easy way to \textbf{remove} space from an existing
object whereas augmenting one to \textbf{add} space is very easy.

\begin{lstlisting}[language=cpp]
template <class.... Types>
class Variant {
public:
  constexpr Variant() noexcept
      : which{-1}, storage{{std::nullvar, std::nullvar}} {}

  template <std::size_t I, class... Args>
  explicit constexpr Variant(
      in_place_t (&tag)(std::integral_constant<std::size_t, I>), Args&&... args)
      : which{0}, storage{{{tag, std::forward<Args>(args)...}, std::nullvar}} {}

  /* ... other in-place constructors ... */

  template <class U>  // SFINAE
  constexpr Variant(U&& u)
      : which{0}, storage{{{std::forward<U>(u)}, std::nullvar}} {}

  Variant(const Variant& that)
      : which{0}, storage{{that.storage[that.which], std::nullvar}} {}

  /* Variant(Variant&& that); */

  ~Variant() = default;

  template <size_t I, class... Args>
  void emplace(Args&&... args) {
    try_([&] {
      storage[!which].template emplace<I>(std::forward<Args>(args)...);
      storage[which] = std::nullvar;
      which = !which;
    });
  }

  /* ... other emplace ... */

  template <class U>  // SFINAE
  Variant& operator=(U&& u) {
    using T = get_best_match_t<Types..., U&&>;
    if (index() == find_index<T, Types...>{}) {
      storage[which] = std::forward<U>(u);
    } else {
      emplace<T>(std::forward<U>(u));
    }
    return *this;
  }

  /*
  Variant& operator=(const Variant& that);
  Variant& operator=(Variant&& that);
  */

  constexpr int index() const noexcept { return storage[which].index(); }

  constexpr const std::type_info& type() const noexcept {
    return storage[which].type();
  }

  void swap(Variant& that)
      noexcept(noexcept(swap(storage[which], that.storage[that.which]))) {
    swap(storage[which], that.storage[that.which]);
  }

private:
  template <class F>
  void try_(F&& f) {
    try {
      std::forward<F>(f)();
    } catch (const std::bad_variant_assign& ex) {
      ex.rethrow_nested();
    }
  }

  int which;

  std::array<std::variant<std::nullvar_t, Types...>, 2> storage;
};
\end{lstlisting}

\section{Implementation}
An implementation of the proposed \texttt{variant} design is available at \cite{MPark.Variant}.

\section{Acknowledgements}

\begin{itemize}
  \item \textbf{Eric Friedman} and \textbf{Itay Maman} for the development of
    \cite{Boost.Variant}.
  \item \textbf{Agust\'in Berg\'e} (a.k.a K-ballo) for the development of
    \cite{Eggs.Variant}.
  \item \textbf{Axel Naumann} for writing \cite{N4542} and its predecessors
    which started the discussion.
  \item \textbf{David Sankel} for deep design discussions and encouraging me to
    present my ideas during CppCon 2015.
  \item \textbf{Kirk Shoop} for design discussions at CppCon 2015.
  \item \textbf{Eric Niebler} for letting me know that submitting a proposal is a
    must in order to be considered for standardization.
  \item \textbf{Geoffrey Romer} for encouraging me to write this paper since
    CppCon 2014.
  \item \textbf{Andrei Alexandrescu} for starting the work on \texttt{variant},
    writing Dr. Dobb's articles back in 2002, and for encouraging me to
    write this paper.
  \item Everyone on \textbf{std-proposals} mailing list who passionately share
    their thoughts, ideas, and opinions.

\end{itemize}

A special thank you to \textbf{Jason Lucas} for initially introducing me to the
multi-method problem, and for the endless design and tradeoff discussions over
the past few years!

\section{References}
\renewcommand{\section}[2]{}%
\begin{thebibliography}{9}
  \bibitem[N3449]{N3449}
    Bjarne Stroustrup,
    \emph{Open and Efficient Type Switch for C++}\newline
    \url{http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3449.pdf}
  \bibitem[N3915]{N3915}
    Peter Sommerlad,
    \emph{apply() call a function with arguments from a tuple (V3)}\newline
    \url{http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3915.pdf}
  \bibitem[N4542]{N4542}
    Axel Naumann,
    \emph{Variant: a type-safe union (v4)}\newline
    \url{http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4542.pdf}
  \bibitem[P0050]{P0050}
    Vicente J. Botet Escriba,
    \emph{C++ generic match function}\newline
    \url{https://github.com/viboes/tags/blob/master/doc/proposals/match/P0050.pdf}
  \bibitem[P0051]{P0051}
    Vicente J. Botet Escriba,
    \emph{C++ generic overload functions}\newline
    \url{https://github.com/viboes/tags/blob/master/doc/proposals/overload/P0051.pdf}
  \bibitem[The Billion Dollar Mistake]{NullRef}
    Tony Hoare,
    \emph{Null References: The Billion Dollar Mistake}\newline
    \url{http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare}
  \bibitem[Mach7]{Mach7}
    Yuriy Solodkyy, Gabriel Dos Reis, Bjarne Stroustrup,
    \emph{Mach7: Pattern Matching for C++}\newline
    \url{https://github.com/solodon4/Mach7}
  \bibitem[Boost.Variant]{Boost.Variant}
    Eric Friedman, Itay Maman,
    \emph{Boost.Variant}\newline
    \url{http://www.boost.org/doc/libs/1_59_0/doc/html/variant.html}
  \bibitem[Eggs.Variant]{Eggs.Variant}
    Agust\'in Berg\'e,
    \emph{Eggs.Variant}\newline
    \url{http://eggs-cpp.github.io/variant}
  \bibitem[MPark.Variant]{MPark.Variant}
    Michael Park,
    \emph{Variant: Discriminated Union with Value Semantics}\newline
    \url{https://github.com/mpark/variant}
  \bibitem[C++ Core Guidelines]{CCG}
    Bjarne Stroustrup, Herb Sutter
    \emph{C++ Core Guidelines}\newline
    \url{https://github.com/isocpp/CppCoreGuidelines}
\end{thebibliography}

\end{document}