New issue from Ruslan Arutyunyan: "§[alg.merge] Wording tweaks"

Author: Dani-Hub

xml/issue4464.xml

@@ -0,0 +1,84 @@
+<?xml version='1.0' encoding='utf-8' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd">
+
+<issue num="4464" status="New">
+<title>&sect;[alg.merge] Wording tweaks</title>
+<section><sref ref="[alg.merge]"/></section>
+<submitter>Ruslan Arutyunyan</submitter>
+<date>07 Nov 2025</date>
+<priority>99</priority>
+
+<discussion>
+<b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/837">US 163-262</a></b>
+<p>
+The original text of the “US 163-262” issue says: “Bullets 1.3 and 1.4 and paragraph 3 should say <tt><i>E</i>(e1, e2)</tt> 
+instead of <tt><i>E</i>(e1, e1)</tt>” in [alg.merge]. The problem, though, was introduced when merging 
+<paper num="P3179R9"/> “Parallel Range Algorithms” proposal. The original wording of P3179 does not 
+have parentheses after <tt><i>E</i></tt>. Those extra parameters in <tt><i>E</i></tt> do not bring clarity 
+to `merge` algorithm. The proposed resolution is to strike them through.
+</p>
+</discussion>
+
+<resolution>
+<p>
+This wording is relative to <paper num="N5014"/>.
+</p>
+
+<ol>
+<li><p>Modify <sref ref="[alg.merge]"/>, as indicated:</p>
+
+<blockquote>
+<pre>
+template&lt;class InputIterator1, class InputIterator2,
+         class OutputIterator&gt;
+  constexpr OutputIterator
+    merge(InputIterator1 first1, InputIterator1 last1,
+          InputIterator2 first2, InputIterator2 last2,
+          OutputIterator result);
+[&hellip;]
+template&lt;<i>execution-policy</i> Ep, <i>sized-random-access-range</i> R1, <i>sized-random-access-range</i> R2,
+         <i>sized-random-access-range</i> OutR, class Comp = ranges::less,
+         class Proj1 = identity, class Proj2 = identity&gt;
+  requires mergeable&lt;iterator_t&lt;R1&gt;, iterator_t&lt;R2&gt;, iterator_t&lt;OutR&gt;, Comp, Proj1, Proj2&gt;
+  ranges::merge_result&lt;borrowed_iterator_t&lt;R1&gt;, borrowed_iterator_t&lt;R2&gt;, borrowed_iterator_t&lt;OutR&gt;&gt;
+    ranges::merge(Ep&amp;&amp; exec, R1&amp;&amp; r1, R2&amp;&amp; r2, OutR&amp;&amp; result_r,
+                  Comp comp = {}, Proj1 proj1 = {}, Proj2 proj2 = {});
+</pre>
+<blockquote>
+<p>
+-1- Let:
+</p>
+<ul style="list-style-type: none">
+<li>(1.1) &mdash; <tt><i>N</i></tt> be: [&hellip;]
+</li>
+<li>(1.2) &mdash; `comp` be `less{}`, `proj1` be `identity{}`, and `proj2` be `identity{}`, 
+for the overloads with no parameters by those names;
+</li>
+<li>(1.3) &mdash; <tt><i>E</i><del>(e1, e1)</del></tt> be <tt>bool(invoke(comp, invoke(proj2, e2), invoke(proj1, e1)))</tt>;
+</li>
+<li>(1.4) &mdash; <tt><i>K</i></tt> be the smallest integer in `[0, last1 - first1)` such that 
+for the element `e1` in the position <tt>first1 + <i>K</i></tt> there are at least <tt>N − <i>K</i></tt> 
+elements `e2` in `[first2, last2)` for which <tt><i>E</i><del>(e1, e1)</del></tt> holds,
+and be equal to `last1 - first1` if no such integer exists.
+</li>
+</ul>
+<p>
+-2- <i>Preconditions</i>: The ranges `[first1, last1)` and `[first2, last2)` are sorted with 
+respect to `comp` and `proj1` or `proj2`, respectively. The resulting range does not overlap 
+with either of the original ranges.
+<p/>
+-3- <i>Effects</i>: Copies the first <tt><i>K</i></tt> elements of the range `[first1, last1)` 
+and the first <tt><i>N</i> − <i>K</i></tt> elements of the range `[first2, last2)` into the range 
+<tt>[result, result + <i>N</i>)</tt>. If an element `a` precedes `b` in an input
+range, `a` is copied into the output range before `b`. If `e1` is an element of `[first1, last1)` 
+and `e2` of `[first2, last2)`, `e2` is copied into the output range before `e1` if and only if 
+<tt><i>E</i><del>(e1, e1)</del></tt> is `true`.
+</p>
+</blockquote>
+</blockquote>
+</li>
+</ol>
+
+</resolution>
+
+</issue>