<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 3933: P1467R9 accidentally changed the signatures of certain constructors of std::complex</title>
<meta property="og:title" content="Issue 3933: P1467R9 accidentally changed the signatures of certain constructors of std::complex">
<meta property="og:description" content="C++ library issue. Status: New">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue3933.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#New">New</a> status.</em></p>
<h3 id="3933"><a href="lwg-active.html#3933">3933</a>. P1467R9 accidentally changed the signatures of certain constructors of <code>std::complex</code></h3>
<p><b>Section:</b> 29.4.3 <a href="https://wg21.link/complex">[complex]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Jiang An <b>Opened:</b> 2023-05-16 <b>Last modified:</b> 2023-06-01</p>
<p><b>Priority: </b>4
</p>
<p><b>View other</b> <a href="lwg-index-open.html#complex">active issues</a> in [complex].</p>
<p><b>View all other</b> <a href="lwg-index.html#complex">issues</a> in [complex].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In C++20 and earlier revisions, there are constructors taking two floating-point numbers by value in explicit 
specializations of <code>std::complex</code> for standard floating-point types. Since <a href="https://wg21.link/P1467R9" title=" Extended floating-point types and standard names">P1467R9</a> has 
removed these explicit specializations, the corresponding constructor in the primary template that takes arguments 
by <code>const T&amp;</code> are used instead. As a result, the following program becomes ill-formed after the changes.
</p>
<blockquote><pre>
#include &lt;complex&gt;

int main()
{
  volatile double x = 0.0;
  std::complex&lt;double&gt; z{x, x}; // <span  style="color:#C80000;font-weight:bold">ill-formed due to P1467R9 because const double&amp; cannot be bound to a volatile double lvalue</span>
}
</pre></blockquote>
<p>
Currently, libstdc++ has implemented complex specializations for extended floating-point types, but the corresponding 
constructors of these specializations takes two arguments by value, which is consistent with old specializations.
<p/>
It seems that it's unintended to change the signatures of these constructors. Perhaps we should restore the signatures for 
required specializations.
</p>

<p>
<b>Daniel:</b>
<p/>
Not only constructors are affected, but also all assignment operators taking the <code>value_type</code> as
parameter and I suggest that LEWG should have a look at this issue.
</p>

<p><i>[2023-05-20; Daniel comments and suggests wording]</i></p>

<p>
The wording below attempts to restore the exact previous behaviour: For all floating-point types the 
function parameter types are "by value" and for other types are "by const reference". The wording adds for 
specification purposes a dependency to the concept <code>std::floating_point</code>, but that doesn't mean that an 
implementation couldn't realize the required effects without usage of concepts or the <code>&lt;type_traits&gt;</code>
header.
<p/>
Note that we have already precedence for similar cases where we later reintroduced concept requirements to library
parts where no concept dependencies had exist before, such as the <code>iterator_traits</code> specialization for
pointers (to object) or the additional constraints of <code>set</code>'s member function 
<code>iterator erase(const_iterator position)</code> or the constraint for <code>reverse_iterator::operator-&gt;()</code>,
just to name a few.
<p/>
One alternative approach could be to switch to "by-value" signatures only for the affected signatures. This could 
affect user-defined floating-point-like types such as those with an arbitrary precision, therefore I started with 
the most conservative approach restoring the original effects that was present in the
working draft <a href="https://wg21.link/N4910" title=" Working Draft, Standard for Programming Language C++">N4910</a> and older ones. It might we worth pointing out that the existing "setter"
functions <code>imag</code> and <code>real</code> have always been using "by-value" signatures for all specializations.
<p/>
There exists also the possible argument to close this issue as NAD based on the argument that all existing 
non-member operators taking a <code>value_type</code> argument had always been defined to use <code>const T&amp;</code>
as parameter (such as the <code>operator@(const T&amp; lhs, const complex&lt;T&gt;&amp; rhs)</code> forms).
<p/>
My main argument to solve this issue as shown below is based on the ground that the refactoring done by
<a href="https://wg21.link/P1467R9" title=" Extended floating-point types and standard names">P1467R9</a> was mainly inspired to simplify the existing wording and to make it more easy to
integrate the addition of the extended floating-point types here, as quoted from 
<a href="https://wg21.link/p1467r9#complex">P1467R9 section 6.6. <code>&lt;complex&gt;</code></a>:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
[&hellip;] The explicit specializations of <code>std::complex&lt;T&gt;</code> are removed. The only differences between 
the explicit specializations was the explicit-ness of the constructors that take a complex number of a different type. 
</blockquote>
<p>
This issue has some overlap with LWG <a href="lwg-active.html#3934" title="std::complex&lt;T&gt;::operator=(const T&amp;) has no specification (Status: New)">3934</a><sup><a href="https://cplusplus.github.io/LWG/issue3934" title="Latest snapshot">(i)</a></sup>, which suggests a yet missing specification for
the assignment operator taking the <code>value_type</code> as parameter.
</p>

<p><i>[2023-06-01; Reflector poll]</i></p>

<p>
Set priority to 4 after reflector poll.
</p>
<p>
Several votes for NAD, as this only affects <code>volatile</code> arguments,
so this might even be an accidental improvement.
</p>



<p id="res-3933"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4950" title=" Working Draft, Standard for Programming Language C++">N4950</a>.
</p>

<ol>
<li>
<p>Modify 29.4.3 <a href="https://wg21.link/complex">[complex]</a>, class template <code>complex</code> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  template&lt;class T&gt; class complex {
  public:
    using value_type = T;

    <ins>constexpr complex(T re = T(), T im = T()) requires floating_point&lt;T&gt;;</ins>
    constexpr complex(const T&amp; re = T(), const T&amp; im = T()) <ins>requires (!floating_point&lt;T&gt;)</ins>;
    [&hellip;]
    <ins>constexpr complex&amp; operator= (T) requires floating_point&lt;T&gt;;</ins>
    constexpr complex&amp; operator= (const T&amp;) <ins>requires (!floating_point&lt;T&gt;)</ins>;
    <ins>constexpr complex&amp; operator+=(T) requires floating_point&lt;T&gt;;</ins>
    constexpr complex&amp; operator+=(const T&amp;) <ins>requires (!floating_point&lt;T&gt;)</ins>;
    <ins>constexpr complex&amp; operator-=(T) requires floating_point&lt;T&gt;;</ins>
    constexpr complex&amp; operator-=(const T&amp;) <ins>requires (!floating_point&lt;T&gt;)</ins>;
    <ins>constexpr complex&amp; operator*=(T) requires floating_point&lt;T&gt;;</ins>
    constexpr complex&amp; operator*=(const T&amp;) <ins>requires (!floating_point&lt;T&gt;)</ins>;
    <ins>constexpr complex&amp; operator/=(T) requires floating_point&lt;T&gt;;</ins>
    constexpr complex&amp; operator/=(const T&amp;) <ins>requires (!floating_point&lt;T&gt;)</ins>;
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>

<li>
<p>Modify 29.4.4 <a href="https://wg21.link/complex.members">[complex.members]</a> as indicated:</p>

<blockquote>
<pre>
<ins>constexpr complex(T re = T(), T im = T()) requires floating_point&lt;T&gt;;</ins>
constexpr complex(const T&amp; re = T(), const T&amp; im = T()) <ins>requires (!floating_point&lt;T&gt;)</ins>;
</pre>
<blockquote>
<p>
-1- <i>Postconditions</i>: <code>real() == re &amp;&amp; imag() == im</code> is <code>true</code>.
</p>
</blockquote>
</blockquote>
</li>

<li>
<p>Modify 29.4.5 <a href="https://wg21.link/complex.member.ops">[complex.member.ops]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note</i>: We have an pre-existing specification hole that the effects of the non-compound assignment 
operator taking the <code>value_type</code> as parameter are nowhere specified. This is going to be submitted as a
separate issue, see LWG <a href="lwg-active.html#3934" title="std::complex&lt;T&gt;::operator=(const T&amp;) has no specification (Status: New)">3934</a><sup><a href="https://cplusplus.github.io/LWG/issue3934" title="Latest snapshot">(i)</a></sup>.]
</p>
</blockquote>

<blockquote>
<pre>
<ins>constexpr complex&amp; operator+=(T rhs) requires floating_point&lt;T&gt;;</ins>
constexpr complex&amp; operator+=(const T&amp; rhs) <ins>requires (!floating_point&lt;T&gt;)</ins>;
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: Adds the scalar value <code>rhs</code> to the real part of the complex value <code>*this</code> and 
stores the result in the real part of <code>*this</code>, leaving the imaginary part unchanged.
<p/>
-2- <i>Returns</i>: <code>*this</code>.
</p>
</blockquote>
<pre>
<ins>constexpr complex&amp; operator-=(T rhs) requires floating_point&lt;T&gt;;</ins>
constexpr complex&amp; operator-=(const T&amp; rhs) <ins>requires (!floating_point&lt;T&gt;)</ins>;
</pre>
<blockquote>
<p>
-3- <i>Effects</i>: Subtracts the scalar value <code>rhs</code> from the real part of the complex value <code>*this</code> and 
stores the result in the real part of <code>*this</code>, leaving the imaginary part unchanged.
<p/>
-4- <i>Returns</i>: <code>*this</code>.
</p>
</blockquote>
<pre>
<ins>constexpr complex&amp; operator*=(T rhs) requires floating_point&lt;T&gt;;</ins>
constexpr complex&amp; operator*=(const T&amp; rhs) <ins>requires (!floating_point&lt;T&gt;)</ins>;
</pre>
<blockquote>
<p>
-5- <i>Effects</i>: Multiplies the scalar value <code>rhs</code> by the complex value <code>*this</code> and 
stores the result in <code>*this</code>.
<p/>
-6- <i>Returns</i>: <code>*this</code>.
</p>
</blockquote>
<pre>
<ins>constexpr complex&amp; operator/=(T rhs) requires floating_point&lt;T&gt;;</ins>
constexpr complex&amp; operator/=(const T&amp; rhs) <ins>requires (!floating_point&lt;T&gt;)</ins>;
</pre>
<blockquote>
<p>
-7- <i>Effects</i>: Divides the scalar value <code>rhs</code> into the complex value <code>*this</code> and 
stores the result in <code>*this</code>.
<p/>
-8- <i>Returns</i>: <code>*this</code>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





</body>
</html>
