Issue update by submitter

Reduction of the discussion text and provision of improved wording

Author: Dani-Hub

xml/issue4320.xml

@@ -39,40 +39,11 @@ there are other ways to obtain this reduction without
 losing <tt>&#x1d4aa;(1)</tt> lookup but it is unclear whether those methods would 
 in fact be faster.
 <p/>
-Regardless, it is necessary for small types. In all cases <tt>N</tt> is capped by
-the maximum block capacity defined in the implementation.
-<p/>
 There is ambiguity as to whether this should result in a change to <tt>hive::insert/emplace</tt> 
 time complexity when discussed on the reflector, as it is unrelated to element numbers (unless 
 all elements fit within one block), but it is related to block capacities, which are defined 
 as part of the `hive` technical specification.
-<p/>
-The exact mechanism by which erased element locations are recorded (for later reuse 
-<sref ref="[hive.overview]"/> p3) in `hive` is not specified in the technical
-specification. The issue is therefore in some ways similar to `deque` `insert/emplace` 
-time complexity, where a `push_back` may in fact result in a <tt>&#x1d4aa;(n)</tt> 
-operation in the number of blocks &mdash; but because we do not specify the storage 
-mechanism in `deque`, we ignore the fact that deques are typically constructed as 
-vectors of pointers to blocks, and therefore any insert may trigger vector expansion. 
-This was also the reasoning discussed for `hive` during LWG talks, since it can also 
-be implemented as a vector of pointers to blocks.
-<p/>
-In addition, if we were to support approaches involving bitset stacking, this would 
-also affect functions which can erase elements, since the number of modifications to 
-the bitset-stack of a given block would increase by 1 with every 64x increase (assuming 
-64-bit words) in block capacity.
 </p>
-<blockquote class="note">
-<p>
-I do not personally believe any wording change are necessary here, based on
-precedents set by the existing standard and what has been conveyed to me
-in the past regarding this topic (<tt>&#x1d4aa;</tt> complexity within blocks). 
-However reflector discussion on the subject has not been entirely conclusive
-since the relevance of some time complexity involves a degree of subjectivity. 
-This issue has therefore been submitted in order for a definitive conclusion 
-to be reached on the issue.
-</p>
-</blockquote>
 <p>
 <b>Changes necessary:</b>
 <p/>
@@ -116,9 +87,7 @@ affect the outcome wording of that issue for `unique`.
 </p>
 </blockquote>
 
-</discussion>
-
-<resolution>
+<superseded>
 <p>
 This wording is relative to <paper num="N5014"/>.
 </p>
@@ -372,6 +341,45 @@ at worst <tt>&#x1d4aa;(log n)</tt> in the capacity of each block containing the
 
 </li>
 
+</ol>
+</superseded>
+
+<note>2025-09-17; Matt comments and provides improved wording</note>
+<p>
+Having looked at this in more detail, I believe only a blanket wording change to the 
+hive.overview is necessary, specifically <sref ref="[hive.overview]"/> p3, such that 
+the time complexity is limited to "techniques to identify the memory locations of 
+erased elements"
+</p>
+</discussion>
+
+<resolution>
+<p>
+This wording is relative to <paper num="N5014"/>.
+</p>
+
+<ol>
+
+<li><p>Modify <sref ref="[hive.overview]"/> as indicated:</p>
+
+<blockquote>
+<p>
+-1- A `hive` is a type of sequence container that provides constant-time insertion and erasure 
+operations. Storage is automatically managed in multiple memory blocks, referred 
+to as element blocks. Insertion position is determined by the container, and may re-use the memory 
+locations of erased elements.
+<p/>
+-2- [&hellip;]
+<p/>
+-3- Erasures use unspecified techniques <del>of constant time complexity</del> to identify the memory 
+locations of erased elements, which are subsequently skipped during iteration <ins>in constant time</ins>, 
+as opposed to relocating subsequent elements during erasure. <ins>These techniques may be at worst 
+logarithmic in the capacity of the element block erased from.</ins>
+</p>
+</blockquote>
+
+</li>
+
 </ol>
 </resolution>