<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 120: Can an implementor add specializations?</title>
<meta property="og:title" content="Issue 120: Can an implementor add specializations?">
<meta property="og:description" content="C++ library issue. Status: CD1">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue120.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#CD1">CD1</a> status.</em></p>
<h3 id="120"><a href="lwg-defects.html#120">120</a>. Can an implementor add specializations?</h3>
<p><b>Section:</b> 16.4.5.3 <a href="https://wg21.link/reserved.names">[reserved.names]</a> <b>Status:</b> <a href="lwg-active.html#CD1">CD1</a>
 <b>Submitter:</b> Judy Ward <b>Opened:</b> 1998-12-15 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#reserved.names">issues</a> in [reserved.names].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>

<p>The original issue asked whether a library implementor could
specialize standard library templates for built-in types.  (This was
an issue because users are permitted to explicitly instantiate
standard library templates.)</p>

<p>Specializations are no longer a problem, because of the resolution
to core issue 259.  Under the proposed resolution, it will be legal
for a translation unit to contain both a specialization and an
explicit instantiation of the same template, provided that the
specialization comes first.  In such a case, the explicit
instantiation will be ignored.  Further discussion of library issue
120 assumes that the core 259 resolution will be adopted.</p>

<p>However, as noted in lib-7047, one piece of this issue still
remains: what happens if a standard library implementor explicitly
instantiates a standard library templates?  It's illegal for a program
to contain two different explicit instantiations of the same template
for the same type in two different translation units (ODR violation),
and the core working group doesn't believe it is practical to relax
that restriction.</p>

<p>The issue, then, is: are users allowed to explicitly instantiate
standard library templates for non-user defined types?  The status quo
answer is 'yes'.  Changing it to 'no' would give library implementors
more freedom.</p>

<p>This is an issue because, for performance reasons, library
implementors often need to explicitly instantiate standard library
templates.  (for example, std::basic_string&lt;char&gt;)  Does giving
users freedom to explicitly instantiate standard library templates for
non-user defined types make it impossible or painfully difficult for
library implementors to do this?</p>

<p>John Spicer suggests, in lib-8957, that library implementors have a
mechanism they can use for explicit instantiations that doesn't
prevent users from performing their own explicit instantiations: put
each explicit instantiation in its own object file.  (Different
solutions might be necessary for Unix DSOs or MS-Windows DLLs.)  On
some platforms, library implementors might not need to do anything
special: the "undefined behavior" that results from having two
different explicit instantiations might be harmless.</p>



<p id="res-120"><b>Proposed resolution:</b></p>
  <p>Append to 16.4.5.3 <a href="https://wg21.link/reserved.names">[reserved.names]</a> paragraph 1: </p>
  <blockquote><p>
    A program may explicitly instantiate any templates in the standard
    library only if the declaration depends on the name of a user-defined
    type of external linkage and the instantiation meets the standard library
    requirements for the original template.
  </p></blockquote>

<p><i>[Kona: changed the wording from "a user-defined name" to "the name of
  a user-defined type"]</i></p>




<p><b>Rationale:</b></p>
<p>The LWG considered another possible resolution:</p>
<blockquote>
  <p>In light of the resolution to core issue 259, no normative changes
  in the library clauses are necessary.  Add the following non-normative
  note to the end of 16.4.5.3 <a href="https://wg21.link/reserved.names">[reserved.names]</a> paragraph 1:</p>
  <blockquote><p>
    [<i>Note:</i> A program may explicitly instantiate standard library
    templates, even when an explicit instantiation does not depend on
    a user-defined name. <i>--end note</i>]
  </p></blockquote>
</blockquote>

<p>The LWG rejected this because it was believed that it would make
  it unnecessarily difficult for library implementors to write
  high-quality implementations.  A program may not include an
  explicit instantiation of the same template, for the same template
  arguments, in two different translation units.  If users are
  allowed to provide explicit instantiations of Standard Library
  templates for built-in types, then library implementors aren't,
  at least not without nonportable tricks.</p>

<p>The most serious problem is a class template that has writeable
  static member variables.  Unfortunately, such class templates are
  important and, in existing Standard Library implementations, are
  often explicitly specialized by library implementors: locale facets,
  which have a writeable static member variable <code>id</code>.  If a
  user's explicit instantiation collided with the implementations
  explicit instantiation, iostream initialization could cause locales
  to be constructed in an inconsistent state.</p>

<p>One proposed implementation technique was for Standard Library
  implementors to provide explicit instantiations in separate object
  files, so that they would not be picked up by the linker when the
  user also provides an explicit instantiation.  However, this
  technique only applies for Standard Library implementations that
  are packaged as static archives.  Most Standard Library
  implementations nowadays are packaged as dynamic libraries, so this
  technique would not apply.</p>

<p>The Committee is now considering standardization of dynamic
  linking.  If there are such changes in the future, it may be
  appropriate to revisit this issue later.</p>





</body>
</html>
