New issue from Matt Bentley: "hive::unique time complexity should incorporate potential block removal complexity"

Author: Dani-Hub

xml/issue4323.xml

@@ -0,0 +1,102 @@
+<?xml version='1.0' encoding='utf-8' standalone='no'?>
+<!DOCTYPE issue SYSTEM "lwg-issue.dtd">
+
+<issue num="4323" status="New">
+<title>`hive::unique` time complexity should incorporate potential block removal complexity</title>
+<section>
+<sref ref="[hive.operations]"/>
+</section>
+<submitter>Matt Bentley</submitter>
+<date>24 Aug 2025</date>
+<priority>99</priority>
+
+<discussion>
+<p>
+Currently we specify for `erase` <sref ref="[hive.modifiers]"/> p16:
+</p>
+<blockquote><p>
+"<i>Complexity:</i> Linear in the number of elements erased. Additionally, if
+any active blocks become empty of elements as a result of the function
+call, at worst linear in the number of element blocks."
+</p></blockquote>
+<p>
+This is to allow for potential `hive` implementations as vectors of
+pointers to blocks, as opposed to linked-lists of blocks (reference
+implementation approach). In that scenario removing a block would
+involve a vector erasure and subsequent pointer-to-block relocations.
+swap-and-pop of block pointers would not work as this would re-arrange
+the sequence during erasure. Anyway, we have neglected to apply this
+same complexity to `hive::unique`. It would be rare that this would occur
+for `unique`, as it would involve (1) a block <i>A</i> with only one non-erased
+element left in it and (2) a block <i>B</i> preceding/following block 
+<i>A</i> in the sequence, whose last/first element is equal to the element 
+in block <i>A</i>. But it is possible, so the same consideration in terms 
+of time complexity applies.
+</p>
+<blockquote class="note">
+<p>
+This is a separate but related issue to LWG <iref ref="4320"/>, but it would 
+affect the outcome wording of that issue for `unique`.
+</p>
+</blockquote>
+</discussion>
+
+<resolution>
+<p>
+This wording is relative to <paper num="N5014"/>.
+</p>
+
+<ol>
+
+<li><p>Modify <sref ref="[hive.operations]"/> as indicated:</p>
+
+<blockquote class="note">
+<p>
+[<i>Drafting note:</i> If issue LWG <iref ref="4320"/> is decided to be acted upon and 
+the proposed solution accepted, the proposed complexity wording becomes:
+</p>
+<blockquote><p>
+-11- <i>Complexity</i>: If `empty()` is `false`, exactly `size() - 1` applications 
+of the corresponding predicate, otherwise no applications of the predicate. 
+<ins>For each element erased as a result of this function call, at worst <tt>&#x1d4aa;(log n)</tt> 
+in the capacity of each block containing the element. Additionally, if any active blocks become 
+empty of elements as a result of the function call, at worst linear in the number of element 
+blocks.</ins>
+</p></blockquote>
+<p>
+]
+</p>
+</blockquote>
+
+
+<blockquote>
+<pre>
+template&lt;class BinaryPredicate = equal_to&lt;T&gt;&gt;
+  size_type unique(BinaryPredicate binary_pred = BinaryPredicate());
+</pre>
+<blockquote>
+<p>
+-7- <i>Preconditions</i>: [&hellip;]
+<p/>
+-8- <i>Effects</i>: [&hellip;]
+<p/>
+-9- <i>Returns</i>: [&hellip;]
+<p/>
+-10- <i>Throws</i>: [&hellip;]
+<p/>
+-11- <i>Complexity</i>: If `empty()` is `false`, exactly `size() - 1` applications 
+of the corresponding predicate, otherwise no applications of the predicate. 
+<ins>Additionally, if any active blocks become empty of elements as a result of the 
+function call, at worst linear in the number of element blocks.</ins>
+<p/>
+-12- <i>Remarks</i>: [&hellip;]
+</p>
+</blockquote>
+</blockquote>
+
+</li>
+
+</ol>
+</resolution>
+
+</issue>