N3887.latex

\documentclass[11pt]{article}

\usepackage{xcolor}
\usepackage{fullpage}
\usepackage[colorlinks, allcolors=blue]{hyperref}
\usepackage{listings}
\usepackage{parskip}

\date{}
\title{Consistent Metafunction Aliases}

\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}]{+++},
}

\lstset{
  basicstyle=\footnotesize\ttfamily,
}

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

\begin{document}

\maketitle\vspace{-2cm}

\begin{flushright}
  \begin{tabular}{ll}
  Document \#:&N3887\\
  Date:       &\date{2013-12-26}\\
  Project:    &Programming Language C++\\
              &Library Evolution Group\\
  Reply-to:   &\author{Michael Park}\\
              &\textless\email\textgreater
  \end{tabular}
\end{flushright}

\section{Introduction}
This paper is inspired by \cite{N3655}, section 3 of which was adopted at WG21's
2013 Bristol meeting. That section provided (as did its predecessor
\cite{N3546}) template aliases for the result of \textit{metafunctions} in
\textbf{\textless type\_traits\textgreater}. However, the broader question of
analogous template aliases throughout the remainder of the standard library was
not addressed.

This paper recommends a systematic guideline to steer future WG21 decisions in
deciding when a \textit{metafunction-name\textbf{\_t}} template alias should
accompany a standard library \textit{metafunction}. After applying this
recommended guideline to the entire C++14 standard library, we conclude that
\textbf{tuple\_element\_t} is the only missing alias. We then propose wording
(a) to remedy this lack and (b) to take advantage of the proposed remedy.
Finally, we also present an alternative guideline and its implications, and
provide justifications for favoring the recommended guideline.

\section{Motivation and Scope}
\cite{N3655} provided the motivation for the existence of the \textbf{\_t}
template aliases. The goal of this paper is to introduce a guideline for WG21 to
systematically decide when a \textit{metafunction} in the standard library
should be accompanied by a \textit{metafunction-name\textbf{\_t}} template
alias. Specifically, we want to ensure that future standard library
\textit{metafunctions} stay consistent with those we currently have.

The proposed guideline is the following:

\begin{quote}
  A class template should be accompanied by a
  \textit{metafunction-name\textbf{\_t}} template alias if it provides a public
  member type named \textbf{type} and no other accessible members.
\end{quote}

An exhaustive search through the text of \cite{N3797} reveals that the only class templates that meet the above guideline are the following:
\begin{itemize}
  \item \textit{TransformationTraits} from section 3 of \cite{N3655}.
  \item \textbf{tuple\_element}
\end{itemize}

Since \textbf{tuple\_element\_t} is the only missing template alias,
we propose to add it.

\section{Impact on the Standard}
This proposal is a pure library extension. It does not require any new
language features, it is merely an extension of an existing practice adopted
from \cite{N3655}.

\section{Proposed Wording}

Add to \textbf{\textless tuple\textgreater} synopsis of \cite{N3797}:

\begin{lstlisting}[language=diff]
// 20.4.2.5: tuple helper classes:
+ template<size_t I, class T>
+ using tuple_element_t = typename tuple_element<I, T>::type;
\end{lstlisting}

The definition of \textbf{get} functions in \textbf{\S20.3.4}, and
\textbf{\S20.4.2.6} of \cite{N3797} can be simplified as follows:\footnote{
Note the removal of explicit \textbf{std::} namespace qualifiers and a
standardized placement of \textbf{const} as a drive-by-fix.}

\begin{lstlisting}[language=diff]
// 20.3.4: tuple-like access to pair:
template<size_t I, class T1, class T2>
-  constexpr typename tuple_element<I, std::pair<T1, T2> >::type&
+  constexpr tuple_element_t<I, pair<T1, T2> >&
-    get(std::pair<T1, T2>&) noexcept;
+    get(pair<T1, T2>&) noexcept;

template<size_t I, class T1, class T2>
-  constexpr typename tuple_element<I, std::pair<T1, T2> >::type&&
+  constexpr tuple_element_t<I, pair<T1, T2> > &&
-     get(std::pair<T1, T2>&&) noexcept;
+     get(pair<T1, T2>&&) noexcept;

template<size_t I, class T1, class T2>
-   constexpr const typename tuple_element<I, std::pair<T1, T2> >::type&
+   constexpr const tuple_element_t<I, pair<T1, T2> >&
-     get(const std::pair<T1, T2>&) noexcept;
+     get(const pair<T1, T2>&) noexcept;

// 20.4.2.6, element access:
template <size_t I, class... Types>
-  constexpr typename tuple_element<I, tuple<Types...> >::type&
+  constexpr tuple_element_t<I, tuple<Types...> >&
    get(tuple<Types...>&) noexcept;

template <size_t I, class... Types>
-  constexpr typename tuple_element<I, tuple<Types...> >::type&&
+  constexpr tuple_element_t<I, tuple<Types...> >&&
    get(tuple<Types...>&&) noexcept;

template <size_t I, class... Types>
-  constexpr typename tuple_element<I, tuple<Types...> >::type const&
+  constexpr const tuple_element_t<I, tuple<Types...> >&
    get(const tuple<Types...>&) noexcept;
\end{lstlisting}

\section{Design Decisions}

We considered an alternative guideline:

\begin{quote}
  A class template should be accompanied by a
  \textit{metafunction-name\textbf{\_t}} template alias if it provides a
  public member type named \textbf{type} and possibly other accessible members.
\end{quote}

An exhaustive search through the text of \cite{N3797} reveals that the class
templates that meet this alternative guideline are the following:

\begin{itemize}
  \item \textbf{integral\_constant}
    \begin{itemize}
      \item \textit{TransformationTraits} from section 4 of \cite{N3655}
      \item \textbf{is\_bind\_expression}
      \item \textbf{is\_error\_code\_enum}
      \item \textbf{is\_error\_condition\_enum}
      \item \textbf{is\_placeholder}
      \item \textbf{ratio\_equal}
      \item \textbf{ratio\_greater}
      \item \textbf{ratio\_greater\_equal}
      \item \textbf{ratio\_less}
      \item \textbf{ratio\_less\_equal}
      \item \textbf{ratio\_not\_equal}
      \item \textbf{tuple\_size}
      \item \textbf{uses\_allocator}
    \end{itemize}
  \item \textbf{ratio}
  \item \textbf{ratio\_add}
  \item \textbf{ratio\_divide}
  \item \textbf{ratio\_multiply}
  \item \textbf{ratio\_subtract}
  \item \textbf{reference\_wrapper}
\end{itemize}

This guideline is overly accepting, because we are rarely interested in the
\textbf{type} member of these class templates. Consider
\textbf{integral\_constant} along with all of the class templates listed under
it which inherit from \textbf{integral\_constant}. The class member we are far
more interested in for these class templates is the \textbf{value} member.
For \textbf{ratio}, and \textbf{ratio}\textit{\_operations}, the \textbf{type}
member is simply a type alias for itself, and \textbf{reference\_wrapper}'s
\textbf{type} member is nothing but an identity type alias for T.

Also consider their intended use cases. All of \textbf{is}\textit{\_property},
\textbf{ratio}\textit{\_compare}, and \textbf{uses\_allocator} are intended for
compile-time boolean tests. \textbf{tuple\_size} is intended to acquire the size
of a \textbf{tuple}. \textbf{integral\_constant} is intended to capture a
compile-time value and is sometimes used for tagged dispatch.
\textbf{ratio}\textit{\_operations} are used for compile-time rational
arithmetic. \textbf{reference\_wrapper} is simply intended for containing
references in our containers. The intended use cases make it clear that these
are not \textit{metafunctions} that yield a type as a result.

On the contrary, the proposed guideline captures the correct intended use of the
class templates. If the only member provided for a class template is
\textbf{type}, it is most likely a \textit{metafunction} which yields a type
as a result. This categorization holds true for all of
\textit{TransformationTraits} from section 3 of \cite{N3655} and
\textbf{tuple\_element}. For example, \textbf{add\_const} is a
\textit{metafunction} which yields a const-qualified version of the type as a
result, and \textbf{tuple\_element} is a \textit{metafunction} which yields the
type that lies at a specified index within a list of types as a result.
Therefore providing a template alias for such class templates will be useful for
convenient access to the \textbf{type} member.

\section{Acknowledgements}
Thanks to Walter E. Brown for encouraging me to write this paper.

\section{References}
\renewcommand{\section}[2]{}%
\begin{thebibliography}{9}

  \bibitem[N3546]{N3546}
    Walter E. Brown,
    \emph{TransformationTraits Redux}\newline
    \url{http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3546.pdf}
  \bibitem[N3655]{N3655}
    Walter E. Brown,
    \emph{TransformationTraits Redux, v2}\newline
    \url{http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3655.pdf}
  \bibitem[N3797]{N3797}
    Stefanus Du Toit,
    \emph{Working Draft, Standard for Programming Language C++}\newline
    \url{http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf}

\end{thebibliography}

\end{document}