<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<style type="text/css">
pre {margin-left:20pt; font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace; }
code {font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace; }
pre > i   { font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;  font-style:italic; }
code > i  { font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;  font-style:italic; }
pre > em  { font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;  font-style:italic; }
code > em { font-family: "OCR A Extended", "Consolas", "Lucida Console", monospace;  font-style:italic; }
body { color: #000000; background-color: #FFFFFF; }
del { text-decoration: line-through; color: #8B0040; }
ins { text-decoration: underline; color: #005100; }

p.example   { margin-left: 2em; }
pre.example { margin-left: 2em; }
div.example { margin-left: 2em; }

code.extract { background-color: #F5F6A2; }
pre.extract  { margin-left: 2em; background-color: #F5F6A2;  border: 1px solid #E1E28E; }

p.function    { }
.attribute    { margin-left: 2em; }
.attribute dt { float: left; font-style: italic;  padding-right: 1ex; }
.attribute dd { margin-left: 0em; }

blockquote.std    { color: #000000; background-color: #F1F1F1;  border: 1px solid #D1D1D1;  padding-left: 0.5em; padding-right: 0.5em; }
blockquote.stddel { text-decoration: line-through;  color: #000000; background-color: #FFEBFF;  border: 1px solid #ECD7EC;  padding-left: 0.5empadding-right: 0.5em; ; }
blockquote.stdins { text-decoration: underline;  color: #000000; background-color: #C8FFC8;  border: 1px solid #B3EBB3; padding: 0.5em; }
table.header { border: 0px; border-spacing: 0;  margin-left: 0px; font-style: normal; }
table { border: 1px solid black; border-spacing: 0px;  margin-left: auto; margin-right: auto; }
th { text-align: left; vertical-align: top;  padding-left: 0.4em; border: none;  padding-right: 0.4em; border: none; }
td { text-align: left; vertical-align: top;  padding-left: 0.4em; border: none;  padding-right: 0.4em; border: none; }
</style>

<title>P2042R0 &mdash; Alternate names for make_shared_default_init</title>

</head>
<body>

<table class="header"><tbody>
  <tr>
    <th>Document number:&nbsp;&nbsp;</th><th> </th><td>P2042r0</td>
  </tr>
  <tr>
    <th>Date:&nbsp;&nbsp;</th><th> </th><td>2020-01-11</td>
  </tr>
  <tr>
    <th>Audience:&nbsp;&nbsp;</th><th> </th><td>LEWG</td>
  </tr>
  <tr>
    <th>Reply-to:&nbsp;&nbsp;</th><th> </th><td><address>Andrzej Krzemie&#324;ski &lt;akrzemi1 at gmail dot com&gt;</address></td>
  </tr>
</tbody></table>

<h1>Alternate names for <code>make_shared_default_init</code></h1>

<p> This document is a response to National body comment <a href="https://github.com/cplusplus/nbballot/issues/2">[DE002]</a>,
    which requests to rename functions <code>make_shared_default_init</code>, <code>make_unique_default_init</code> and
    <code>allocate_shared_default_init</code>, as there exist users that incorrectly infer these functions' semantics from
    their names. In this paper we list the suggested alternate names for these functions, which have been collected from
    the reflector discussions.
    </p>


<h2><a name="criteria">Naming criteria</a></h2>

<p> The following (potentially contradictory) criteria have been expressed for the desired name of these functions:
    </p>

<ol>
    <li>Name should be consistent with the original names, as used in Boost implmentation (<code>make_shared_noinit</code>).
        </li>
    <li>Name should be consistent with the core definitions. (Term "default initialization" is already defined
        in the Standard with exactly the semantics in <code>make_shared_default_init</code>.)
        </li>
    <li>Name should be consistent with other names in the Standard Library.
        (We already have <code>std::uninitialized_default_construct</code>.)
        </li>
    <li>Name should not use "init" or "initialize" as to some people this implies that the objects will be left
        in a state that can be inspected without cassing undefined behavior.
        </li>
    <li>Name should reflect the intent of the function, which is, "perform as fast initialization as possible, knowing that
        the next thing that will happen with this values will be to overwrite them."
        </li>
    <li>If an ideal name cannot be found, prefer a name that is confusing (the user realizes that she doesn't know what
        the function is doing) to the name that is misleading (the user is led to believe that she knows what the function
        is doing, whereas the function is actually doing something else).
        </li>
    </ol>


<h2><a name="names">The names</a></h2>

<h3><code>make_shared_default_init</code></h3>

<p> This name is consistent with core language and more-less (<code>make_shared_default_init</code> vs <code>make_shared_default_construct</code>) with the Standard Library.
    The only problem is the issue inidcated in <a href="https://github.com/cplusplus/nbballot/issues/2">[DE002]</a>, that for
    people not familiar with core terms word "init" is misleading as it implies a state that can be read.
    </p>

<h3><code>make_shared_default_construct</code></h3>

<p> Almost same as above, but we get a 100% compatibility with the Standard Library.
    </p>


<h3><code>make_shared_uninitialized</code> (+ a constraint)</h3>

<p> This is what <a href="http://wiki.edg.com/pub/Wg21belfast/LibraryEvolutionWorkingGroup/D1973R0_rename_default_init_funcs.pdf">[P1973r0]</a> proposes.
    This avoids using the name "initialized" and does not mislead people who infer semantics from function name. To some extent the name reflects what
    the function does, because for the types that the function is constrained to, there is little difference between being initialized an uninitialized.
    But this solution has its own issues. First, in addition to name, it changes the design,
    so that the usage of the function is impeded in generic contexts. The name no longer reflects the core terms or the Standard Library names.
    It is also misleading, this time to another group of people, who follow the core terms. "Uninitialized", as in
    <code>std::uninitialized_default_construct</code>, implies that we are left with raw memory and some initialization &mdash; even if vacuous initialization &mdash;
    still needs to be performed by the caller.
    </p>

<h3><code>make_shared_minimal_init</code></h3>

<p> This is what <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1978r0.html">[P1978r0]</a> proposes. Arguably, its name reflects the intention
    somewhat better, as the purpose of invoking this function is to perform as fast initialization as possible for the subsequent value assignment. But it departs
    from core terms, and does not actually address <a href="https://github.com/cplusplus/nbballot/issues/2">[DE002]</a>, because the misleading term "init" is still
    present.</p>


<h3><code>make_shared_noinit</code></h3>

<p> This is the name used in the original implementation in Boost. It addresses <a href="https://github.com/cplusplus/nbballot/issues/2">[DE002]</a>
    as "noinit" implies that no "initialization" is performed. Drawbacks: it doesn't use core terms, and is somewhat misleading as some it might indicate
    that not even vacuous initialization has been performed.
    </p>


<h3><code>make_shared_unsafe_init</code>, <code>make_shared_weak_init</code></h3>

<p> These names have prefixes that alert about something fishy, but they still have "init", which is potentially misleading.
    They do not reflect core terms. They also don't really reflect what the function does. Unless we introduce a new core term
    "weak initialization".
    </p>

<h3><code>make_shared_trivial_init</code></h3>

<p> Same as above, except a bit more misleading, as it implies that it only works for trivial types,
    or that it skips the constructor for types that have one.
    </p>

<h3><code>make_shared_nonvalue_init</code></h3>

<p> "Nonvalue" hints that the produced value may be fishy, but it is not clear if it hints enough that it cannot be read.
    Still, not following core terms, and has "init".
    </p>

<h3><code>make_shared_partially_formed_value</code>, <code>make_shared_with_partially_formed_value</code></h3>

<p> "Partially formed value" sounds dangerous enough to discourage people form reading the value.
    It doesn't contain "init".
    It reflects the intent a bit. But it is not actually true because for types with default constructor
    the value is actually fully formed.
    </p>

<h3><code>make_shared_for_overwrite</code>, <code>make_shared_with_no_guaranteed_value</code></h3>

<p> Clearly reflect the intent. Do not have "init". Do not invent terms. Maybe too descriptive.
    </p>

<h3><code>make_shared_unspecified_value</code></h3>

<p> Uses familiar core terms, maybe somewhat libelarly. Still, the uninitiated may think that unspecified value can be read.
    </p>


<h3><code>make_shared_valueless</code>, <code>make_shared_with_valueless</code></h3>

<p> "Valueless" is used in <code>std::variant</code> and is perhaps sufficiently scarry.
    The two contexts are similar in the sense that in either case you do not want to read the value, but to overwrite it.
    </p>


<h3><code>make_shared_with_discarded_value</code>, <code>make_shared_discarded_value</code></h3>

<p> You do not want to read a discarded value, don't you?
    </p>

<h3><code>make_shared_indeterminate_value</code>, <code>make_shared_with_indeterminate_value</code>, make_shared_indeterminate</h3>

<p> This uses the core term "indeterminate value" which is the right term at least for trivial types. It is not the right term
    for types with default constructor, but the meaning should be sufficiently clear from the context. This makes it incompatible with
    <code>std::uninitialized_default_construct</code>.
    </p>


<h2 name="other_opts">Other options</h2>

<p> The reflector discussions also suggested that the core terms themselves could be changed
    to be easier to consume by the uninitiated. However, this would require the coordination between
    the working groups that may not be feasible for C++20. So, either this idea needs to be abandoned,
    or LEWG can preemptively invent intuitive terms in hopes that CWG will adapt in the future.
    </p>


<h2 name="macro">The feature test macro</h2>

<p>It should be noted that <code>std::make_shared_default_init</code> is acompanied by the
corresponding feature test macro <code>__cpp_lib_smart_ptr_default_init</code>. Should LEWG decide to change the name of the
function, does the name of the macro also require a change?
</p>




<h2><a name="literature">References</a></h2>

<ol>
  <li>[DE002],
      "Rename make_unique/shared_default_init to make_unique/shared_nonvalue_init",
	  (DE002, <a href="https://github.com/cplusplus/nbballot/issues/2">https://github.com/cplusplus/nbballot/issues/2</a>).
	  </li>

  <li>[P1973r0], Nicolai Josuttis,
      "Rename '_default_init' Functions",
	  (<a href="http://wiki.edg.com/pub/Wg21belfast/LibraryEvolutionWorkingGroup/D1973R0_rename_default_init_funcs.pdf">http://wiki.edg.com/pub/Wg21belfast/LibraryEvolutionWorkingGroup/D1973R0_rename_default_init_funcs.pdf</a>).
	  </li>

  <li>[P1020r1], Glen Joseph Fernandes, Peter Dimov,
      "Smart pointer creation with default initialization",
	  (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1020r1.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1020r1.html</a>).
	  </li>

  <li>Greg Colvin, Beman Dawes, Peter Dimov, Glen Fernandes,
      Boost.SmartPtr (<a href="https://www.boost.org/doc/libs/1_71_0/libs/smart_ptr/doc/html/smart_ptr.html#introduction">https://www.boost.org/doc/libs/1_71_0/libs/smart_ptr/doc/html/smart_ptr.html#introduction</a>).
      </li>

  <li>[P1978r0], Andrzej Krzemieński, Glen Joseph Fernandes, Nevin Liber, Peter Dimov,
      "Rename <code>make_shared_default_init</code> functions and do nothing more",
	  (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1978r0.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1978r0.html</a>).
	  </li>
</ol>

</body>
</html>
