New issue from Jan Schultke: "<cfloat> should be specified not to contain all macros in <float.h>"

Author: Dani-Hub

xml/issue4473.xml

@@ -2,103 +2,43 @@
 <!DOCTYPE issue SYSTEM "lwg-issue.dtd">
 
 <issue num="4473" status="New">
-<title>`sender_concept` tags should use `_tag`, not `_t`</title>
-<section><sref ref="[execution.syn]"/></section>
-<submitter>Arthur O'Dwyer</submitter>
-<date>12 Nov 2025</date>
+<title><tt>&lt;cfloat&gt;</tt> should be specified not to contain all macros in <tt>&lt;float.h&gt;</tt></title>
+<section><sref ref="[cfloat.syn]"/></section>
+<submitter>Jan Schultke</submitter>
+<date>13 Nov 2025</date>
 <priority>99</priority>
 
 <discussion>
 <p>
-In November 2025 it was observed that the STL has exactly two places where member typedefs 
-are used to specify what concepts a type claims to conform to. The first is iterator concept 
-tags, and the second is sender/receiver concept tags. The former match widespread Boost 
-practice in using the suffix "`_tag`", e.g.
+Consider <sref ref="[climits.syn]"/> paragraph 1:
 </p>
-<blockquote><pre>
-struct forward_iterator_tag {};
-using iterator_category = std::forward_iterator_tag;
-using iterator_concept = std::forward_iterator_tag;
-</pre></blockquote>
+<blockquote><p>
+The header <tt>&lt;climits&gt;</tt> defines all macros the same as the C standard library header 
+<tt>&lt;limits.h&gt;</tt>, except that it does not define the macro `BITINT_MAXWIDTH`.
+</p></blockquote>
 <p>
-The latter, adopted for C++26, currently use the suffix "_t", e.g.
+Similarly, <tt>&lt;cfloat&gt;</tt> is missing various macros from C's <tt>&lt;float.h&gt;</tt>, 
+but this is not stated.
 </p>
-<blockquote><pre>
-struct sender_t {};
-struct receiver_t {};
-struct scheduler_t {};
-struct operation_state_t {};
-using sender_concept = sender_t;
-using receiver_concept = receiver_t;
-using scheduler_concept = scheduler_t;
-using operation_state_concept = operation_state_t;
-</pre></blockquote>
-<p>
-For consistency with the existing STL and with Boost, we should rename each of these four C++26 types:
-</p>
-<ul>
-<li><p>`sender_t` ==> `sender_tag`</p></li>
-<li><p>`receiver_t` ==> `receiver_tag`</p></li>
-<li><p>`scheduler_t` ==> `scheduler_tag`</p></li>
-<li><p>`operation_state_t` ==> `operation_state_tag`</p></li>
-</ul>
-<p>
-Note the distinction between member-typedef "concept tags" like `forward_iterator_tag` and 
-`execution::sender_t(ag)`, as opposed to "tag constants" used in function signatures like 
-`defer_lock_t` and `execution::get_allocator_t`.
-<p/>
-Concept tags:
-</p>
-<ul>
-<li><p>intended for use as member typedefs</p></li>
-<li><p>member typedef's name ends in `_category` or `_concept`</p></li>
-<li><p>tag type's name ends in `_tag`</p></li>
-<li><p>unsuffixed form is a concept, e.g. `concept forward_iterator`, `concept execution::sender`, `concept execution::operation_state`</p></li>
-<li><p>always a 1:1 relationship between a tag and a concept</p></li>
-<li><p>frequently used as a base class for more tag types</p></li>
-</ul>
-<p>
-Tag constants:
-</p>
-<ul>
-<li><p>never used as member typedefs</p></li>
-<li><p>tag type's name ends in `_t`</p></li>
-<li><p>unsuffixed form is a constant global variable, e.g. `constexpr auto allocator_arg`, `in_place_type`, 
-`defer_lock`, `adopt_lock`, `execution::set_value`, `execution::get_allocator`</p></li>
-<li><p>never represent a concept</p></li>
-<li><p>never used as a base class for more tag types</p></li>
-</ul>
-<p>
-Examples of "concept tags" from outside the STL include these from Boost:
-</p>
-<ul>
-<li><p>Boost.Graph has member typedef `directed_category` corresponding to `directed_tag`, `undirected_tag`, etc.</p></li>
-<li><p>Boost.Graph has member typedef `traversal_category` corresponding to `vertex_list_graph_tag`, etc.</p></li>
-<li><p>Boost.Fusion has member typedef `fusion_tag` corresponding to `deque_tag`, `vector_tag`, etc.</p></li>
-<li><p>Boost.Numeric.Odeint has member typedef `stepper_category` corresponding to `stepper_tag`, etc.</p></li>
-<li><p>Boost.Numeric.Ublas has member typedef `dispatch_category` corresponding to `row_major_tag`, `column_major_tag`, etc.</p></li>
-<li><p>Boost.Numeric.Ublas has member typedef `type_category` corresponding to `tensor_tag`, etc.</p></li>
-<li><p>Boost.Numeric.Ublas has member typedef `storage_category` corresponding to `dense_tag`, `packed_tag`, 
-`sparse_tag`, etc.</p></li>
-</ul>
+</discussion>
+
+<resolution>
 <p>
-A few more examples can be found via GitHub search:
+This wording is relative to <paper num="N5014"/>.
 </p>
-<ul>
-<li><p><a href="https://github.com/search?q=language%3AC%2B%2B+%2F%28%3F-i%29using+.*_concept+%3D+.*_tag%3B%2F+NOT+%2Fitera%3Ftor_concept%2F&amp;type=code">[search-results A]</a></p></li>
-<li><p><a href="https://github.com/search?q=language%3AC%2B%2B+%2F%28%3F-i%29using+.*_category+%3D+.*_tag%3B%2F+NOT+%2Fiterator_category%2F&amp;type=code">[search-results B]</a></p></li>
-</ul>
+
+<ol>
+<li><p>Modify <sref ref="[cfloat.syn]"/> as indicated:</p>
+
+<blockquote>
 <p>
-(Notably Jared Hoberock's Croquet, a "prototype implementation of C++ executors, senders, &amp; receivers" from ~2019, 
-used `sender_tag` in place of `sender_t`.)
-<p/>
-For consistency with the existing library, we should rename each of these four C++26 types, e.g. `sender_t` to 
-`sender_tag`... and this needs to be done now, in the C++26 cycle, because it cannot be done later (in which case 
-we will have failed the community).
+-1- The header <tt>&lt;cfloat&gt;</tt> defines all macros the same as the C standard library header 
+<tt>&lt;float.h&gt;</tt><ins>, except that it does not define any macros specifying characteristics 
+of C decimal floating types or C interchange floating types</ins>.
 </p>
-</discussion>
-
-<resolution>
+</blockquote>
+</li>
+</ol>
 </resolution>
 
 </issue>