<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 323: abs() overloads in different headers</title>
<meta property="og:title" content="Issue 323: abs() overloads in different headers">
<meta property="og:description" content="C++ library issue. Status: NAD">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue323.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="323"><a href="lwg-closed.html#323">323</a>. <code>abs()</code> overloads in different headers</h3>
<p><b>Section:</b> 29.7 <a href="https://wg21.link/c.math">[c.math]</a> <b>Status:</b> <a href="lwg-active.html#NAD">NAD</a>
 <b>Submitter:</b> Dave Abrahams <b>Opened:</b> 2001-06-04 <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#c.math">issues</a> in [c.math].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
<p>Currently the standard mandates the following overloads of
abs():</p>

<pre>
    abs(long), abs(int) in &lt;cstdlib&gt;

    abs(float), abs(double), abs(long double) in &lt;cmath&gt;

    template&lt;class T&gt; T abs(const complex&lt;T&gt;&amp;) in &lt;complex&gt;

    template&lt;class T&gt; valarray&lt;T&gt; abs(const valarray&lt;T&gt;&amp;); in &lt;valarray&gt;
</pre>

<p>
The problem is that having only some overloads visible of a function
that works on "implicitly inter-convertible" types is dangerous in
practice. The headers that get included at any point in a translation
unit can change unpredictably during program
development/maintenance. The wrong overload might be unintentionally
selected.
</p>

<p>
Currently, there is nothing that mandates the simultaneous visibility
of these overloads. Indeed, some vendors have begun fastidiously
reducing dependencies among their (public) headers as a QOI issue: it
helps people to write portable code by refusing to compile unless all
the correct headers are #included.
</p>

<p>The same issue may exist for other functions in the library.</p>

<p>Redmond: PJP reports that C99 adds two new kinds of <code>abs</code>: <code>complex</code>,
and <code>int_max_abs</code>.</p>

<p>Related issue: <a href="lwg-defects.html#343" title="Unspecified library header dependencies (Status: Resolved)">343</a><sup><a href="https://cplusplus.github.io/LWG/issue343" title="Latest snapshot">(i)</a></sup>.</p>

<p><i>[
Bellevue:
]</i></p>


<blockquote><p>
The situation is not sufficiently severe to warrant a change.
</p></blockquote>




<p><b>Rationale:</b></p>
<p>The programs that could potentially be broken by this situation are
  already fragile, and somewhat contrived: For example, a user-defined
  class that has conversion overloads both to <code>long</code> and
  to <code>float</code>.  If <code>x</code> is a value of such a class, then
  <code>abs(x)</code> would give the <code>long</code> version if the user
  included &lt;cstdlib&gt;, the <code>float</code> version if the user
  included &lt;cmath&gt;, and would be diagnosed as ambiguous at
  compile time if the user included both headers.  The LWG couldn't
  find an example of a program whose meaning would be changed (as
  opposed to changing it from well-formed to ill-formed) simply by
  adding another standard header.</p>

<p>Since the harm seems minimal, and there don't seem to be any simple
  and noninvasive solutions, this is being closed as NAD.  It is
  marked as "Future" for two reasons.  First, it might be useful to
  define an <code>&lt;all&gt;</code> header that would include all
  Standard Library headers.  Second, we should at least make sure that
  future library extensions don't make this problem worse.</p>





</body>
</html>
