<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2113: Do library implementers have the freedom to add final to non-polymorphic components?</title>
<meta property="og:title" content="Issue 2113: Do library implementers have the freedom to add final to non-polymorphic components?">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2113.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#NAD">NAD</a> status.</em></p>
<h3 id="2113"><a href="lwg-closed.html#2113">2113</a>. Do library implementers have the freedom to add <code>final</code> to non-polymorphic components?</h3>
<p><b>Section:</b> 16.4.6 <a href="https://wg21.link/conforming">[conforming]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-11-30 <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#conforming">issues</a> in [conforming].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>

<p>
Related to LWG <a href="lwg-defects.html#2112" title="User-defined classes that cannot be derived from (Status: C++14)">2112</a><sup><a href="https://cplusplus.github.io/LWG/issue2112" title="Latest snapshot">(i)</a></sup> the question has been raised whether a library implementation <em>may</em> declare
non-polymorphic library components, such as class template <code>std::vector</code> or <code>std::basic_string</code>,
as <code>final</code> class types.
<p/>
This issue is <em>not</em> suggesting to enforce that libraries are required to do that, it is asking
whether libraries should have the freedom to do so.
<p/>
The existing wording in 16.4.6.13 <a href="https://wg21.link/derivation">[derivation]</a> does not give a clear permission to do so. In my opinion
this position should be clarified in either direction.
<p/>
Giving implementations this freedom would have both advantages and disadvantages. Several opponents where
worried about breakage of code of existing user implementations. On the other hand such types where not
designed to be used as base classes. Allowing implementations to mark these components as <code>final</code>
could allow them to provide compile-modes that are intentionally restrictive to the advantage of user code
that want to be alterted about that. Any implementation that would be concerned about user complaints would 
not take advantage of this feature anyway.
<p/>
If agreement exists that such implementation freedom would be useful, wording like
</p>
<blockquote><p>
An implementation may declare additional non-virtual member function signatures within a class as <code>final</code>.
</p></blockquote>
<p>
or
</p>
<blockquote><p>
An implementation may declare additional class without virtual member function signatures as <code>final</code>.
</p></blockquote>
<p>
should be added to 16.4.6 <a href="https://wg21.link/conforming">[conforming]</a> with corresponding exceptions of these rules (e.g. <code>iterator</code>,
<code>unary_function</code>, or <code>pair</code>).
<p/>
If such freedom should not exist, it seems better to clarify this as well, e.g. by adding around 16.4.6.13 <a href="https://wg21.link/derivation">[derivation]</a>:
</p>
<blockquote><p>
An implementation shall not declare any class or any member function signature as <code>final</code>.
</p></blockquote>


<p><i>[2012, Kona]</i></p>

<p>
Move to NAD.
</p>
<p>
Unless the library uses the keyword <code>final</code> in a specification, the user clearly has
freedom to derive from such a class, and so equally clearly, the library vendor does not have
freedom to add a <code>final</code> overrider or class attribute.  Howard observed there may be
some wiggle-room with 'unspecified types' such as those returned from <code>bind</code> expressions,
or iterators, but we did not see a need to further clarify the issue.  Note that, for example,
a <code>vector::iterator</code> may be implemented as a raw pointer, so users cannot generally
assume the ability to derive from unspecified library types.
</p>



<p id="res-2113"><b>Proposed resolution:</b></p>





</body>
</html>
