<html><head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=ISO-UTF8">
<title>Call for Reflection Proposals</title>
</head>
<body style="max-width: 6.5in">
  <table border="0" cellpadding="0" cellspacing="0" style="border-collapse: collapse" bordercolor="#111111" width="607">
    <tr>
      <td width="172" align="left" valign="top">Document number:</td>
      <td width="435">N3814</td>
    </tr>
    <tr>
      <td width="172" align="left" valign="top">Date:</td>
      <td width="435">2013-10-06</td>
    </tr>
    <tr>
      <td width="172" align="left" valign="top">Project:</td>
      <td width="435">Programming Language C++, Reflection Study Group</td>
    </tr>
    <tr>
      <td width="172" align="left" valign="top">Authors:</td>
      <td width="435">Jeff Snyder &lt;<a href="mailto:jeff-isocpp@caffeinated.me.uk">jeff-isocpp@caffeinated.me.uk</a>&gt;</td>
    </tr>
    <tr>
      <td width="172"></td>
      <td width="435">Chandler Carruth &lt;<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>&gt;</td>
    </tr>
    <tr>
      <td width="172" align="left" valign="top">Reply-to:</td>
      <td width="435">Reflection Study Group &lt;<a href="mailto:reflection@isocpp.org">reflection@isocpp.org</a>&gt;</td>
    </tr>
  </table>


<h1>Call for Compile-Time Reflection Proposals</h1>

<p>
<a href="#Introduction">Introduction</a><br/>
<a href="#Targeted-use-cases">Targeted use cases</a><br/>
<a href="#Generation-of-common-functions">1. Generation of common functions</a><br/>
<a href="#Type-transformations">2. Type transformations</a><br/>
<a href="#Compile-time-context-information">3. Compile-time context information</a><br/>
<a href="#Enumeration-of-other-entities">4. Enumeration of other entities</a><br/>
<a href="#Submitting-a-proposal">Submitting a proposal</a><br/>
<a href="#References">References</a><br/>
</p>

<h2><a name="Introduction">Introduction</a></h2>

<p>The reflection study group (SG7) of the C++ standards committee is soliciting
 proposals for features that add compile-time reflection capabilities to C++.
 Whilst all proposals regarding reflection in C++ will be considered, the
 group's current focus is on compile-time reflection. This is because
 the design of compile-time reflection features will likely influence the
 requirements for run-time reflection features.</p>

<p>This call for proposals in open ended; there is no cut-off date. As a
 practical matter, the committee has recently stopped accepting new features for
 the next revision of the language (tentatively C++14), and so the next
 year is a particularly good time to propose features that are targeted at
 inclusion in the following revision of the language (tentatively C++17).</p>

<p>The study group welcomes proposals either with or without formal standard
 wording (often known as &quot;standardese&quot;). Proposals may consist of core
 language extensions, both core language and library extensions or (where
 possible) pure library extensions.</p>

<h2><a name="Targeted-use-cases">Targeted use cases</a></h2>

<p>The reflection study group has identified four broad areas where reflection
 would be useful in C++, and for each area a representative use-case has been
 chosen; these use-cases are outlined below.</p>

<p>In order to facilitate comparison, proposals submitted to the reflection
 study group are encouraged to use one or more of these use cases to demonstrate
 the features they are proposing, in preference to similar use-cases from the
 same area.</p>

<p>These areas, and their corresponding representative use-cases, are as
 follows:</p>

<h3><a name="Generation-of-common-functions">1. Generation of common functions</a></h3>

<p><i>Representative use case: <b>generating equality operators</b></i></p>

<p>There are many functions that generally consist of boilerplate code,
 performing some action for each member of a class. Such functions include
 equality operators, comparison operators, serialization functions, hash
 functions and swap functions.</p>

<p>SG7 would like to see proposals for reflection functionality that would allow
 users to avoid writing repetitive code to implement functions such as these.
 </p>

<h3><a name="Type-transformations">2. Type transformations</a></h3>

<p><i>Representative use case: <b>Struct-of-Arrays vector</b> (see below)</i></p>

<p>There are also cases where it is useful to synthesize a new type based on the
 contents of an existing class. Examples of this include class mocking, creating
 delegates, parallel class hierarchies and the Struct-of-Arrays vector
 (SoA vector).</p>

<h4>2.1 The Struct-of-Arrays vector</h4>
<p>In typical C++ code, an ordered collection of instances of a struct
'<code>S</code>' would be declared using
<code>std::vector&lt;S&gt; s_vec;</code>. This is quick and convenient, but in
some applications it can lead to significantly worse performance than the
CPU is capable of, particularly in vectorized loops over the container. These
performance problems are a consequence of the "array of structs" data layout
used by <code>std::vector&lt;S&gt;</code> <a href="#BrumerNCPaM">[BrumerNCPaM]</a>.

<p>Instead of allocating one array containing instances of <code>S</code>, a
 SoA vector of <code>S</code> would contain one array for each of
 <code>S</code>' members, creating a data layout similar to
 <code>SoA_vector_of_S</code> below.</p>

<p>
<pre>
struct S {
    int a;
    int b;
    int c;
};</pre>
</p>

<p>
<pre>
struct SoA_vector_of_S {
    std::vector&lt;int&gt; as;
    std::vector&lt;int&gt; bs;
    std::vector&lt;int&gt; cs;
};
</pre>
</p>

<p>Whilst having the container's data laid out like this is desirable for
 performance, the interface that <code>SoA_vector_of_S</code> provides is not
 as user-friendly as <code>std::vector</code>'s. Ideally, a reflection-based
 SoA vector implementation would implement the same API as
 <code>std::vector</code>, as far as is possible.</p>

<h3><a name="Compile-time-context-information">3. Compile-time context information</a></h3>

<p><i>Representative use case: <b>replacing <code>assert</code></b></i></p>

<p>We would like to be able to define functions that have access to the
information about the compile-time context of the caller, <i>e.g.</i> the file
name, line number, and the name of the calling function.</p>

<p>Today, there is no way to implement a useful <code>assert</code> function in
 C++ without preprocessor macros, because <code>__FILE__</code>,
 <code>__LINE__</code> and friends are the only way of obtaining compile-time
 context information. This is problematic for any library wishing to provide a
 customized assertion function, since they must introduce a new macro name and
 risk name collisions with their users' code.</p>

<p>This use-case is not limited to replacing the <code>assert</code> macro with
 an exact replica; proposals that improve upon the diagnostic information that
 <code>assert</code> provides are welcome.</p>

<h3><a name="Enumeration-of-other-entities">4. Enumeration of other entities</a></h3>

<p><i>Representative use case: <b>enumerating enums</b></i></p>

<p>Besides class members (see above), there are many entities in C++ that it
 would be useful to enumerate at compile time, such as:</p>

<ul>
<li>types in a namespace</li>
<li>parameters of a function</li>
<li>global variables in a namespace</li>
<li>enumerators in an enumeration</li>
</ul>

<p>There have been many attempts to write a good "enhanced enum" library such as
 <a href="#HusseEnum">[HusseEnum]</a>, which provide extra features such as
 enum-to-string conversion, string-to-enum conversion and checked int-to-enum
 conversion. These libraries generally rely on preprocessor magic to achieve
 their goals, requiring users to write their enums with using unfamiliar
 syntax.</p>

<p>Ideally, proposals in this area would make it possible to implement an
"enhanced enum" without intrusive syntax changes to the declaration of
enums.</p>

<h2><a name="Submitting-a-proposal">Submitting a proposal</a></h2>
<p>The <a href="http://www.isocpp.org/">Standard C++ Foundation</a> has a page
 on their website that provides general guidance on
 <a href="http://isocpp.org/std/submit-a-proposal">submitting a proposal</a>.
 However, where the isocpp.org guidance mentions posting to the std-proposals
 forum, please use the reflection mailing list
 (<a href="mailto:reflection@isocpp.org">reflection@isocpp.org</a>) instead of
 the std-proposals for discussion of ideas and submission of initial proposals
 in response to this call for proposals. The reflection mailing list both is
 open to the public and has a
 <a href="https://groups.google.com/a/isocpp.org/forum/#!aboutgroup/reflection">
 public archive</a>, but you must join the list before posting to it. To join,
 either visit the <a href="https://groups.google.com/a/isocpp.org/forum/#!aboutgroup/reflection">
 google groups page</a> or send a blank email to
 <a href="mailto:reflection+subscribe@isocpp.org">
reflection+subscribe@isocpp.org</a>.

<h2><a name="References">References</a></h2>
<dl>
  <dt><a name="BrumerNCPaM">[BrumerNCPaM]</a></dt>
  <dd><a href="http://channel9.msdn.com/Events/Build/2013/4-329">Eric Brumer: Native Code Performance and Memory: The Elephant in the CPU</a></dd>
  <dt><a name="HusseEnum">[HusseEnum]</a></dt>
  <dd><a href="http://www.codeproject.com/Articles/318690/C-11-Non-intrusive-enum-class-with-reflection-supp">Christoph Husse: C++11 Non-intrusive enum class with Reflection support using Metaprogramming</a></dd>
</dl>
<hr>
</body></html>
