Matt Bentley comments and provides improved wording

Author: Dani-Hub

xml/issue4320.xml

@@ -19,11 +19,10 @@ However the approach to implementation necessary to support 8/16-bit
 types without artificially widening the type storage, as described under
 <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p0447r28.html#non_reference_implementations_info">
 "Additional info for supporting small types" in P0447</a> basically specifies 
-time complexity which is `Log(n)` in the capacity of the element block selected 
-to insert into (when erased element memory locations are available for reuse) but 
-imposes a small maximum block capacity cap. This time complexity only occurs 
+time complexity which is `Log(n)` (on most platforms, log64 or log32) in the 
+capacity of the element block selected to insert into. This time complexity only occurs 
 during the operation to find an erased element memory location within a block 
-which is known to have one.
+which is known to have one, and does not involve the elements themselves.
 <p/>
 This is both the simplest and fastest solution to supporting small types
 in hive without artificial widening that I have come across.
@@ -37,58 +36,21 @@ and other memory-scarse platforms as it reduces the 16-bit-per-element cost of t
 reference implementation down to a 1-bit-per-element cost. For 64-bit and larger types, 
 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.
+in fact be faster. For approaches involving bitset-stacking, the logarithmic 
+complexity also occurs during erasure, specifically adding a couple of extra 
+instructions for every 64x (i.e. bit-depth) increase in block capacity. But again 
+this does not involve the elements and is logarithmic in the capacity of the block 
+erased from.
 <p/>
-There is ambiguity as to whether this should result in a change to <tt>hive::insert/emplace</tt> 
+Regardless, the increased complexity during insertion is necessary for small-type support.
+<p/>
+There was ambiguity as to whether this should result in a change to <tt>hive</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>
-<p>
-<b>Changes necessary:</b>
-<p/>
-Making this change would affect any functions which may reuse existing
-erased-element memory locations. This includes:
-<p/>
-<sref ref="[hive.modifiers]"/>:<br/>
-(`emplace`) p4<br/>
-(range `insert`) p9<br/>
-(fill `insert`) p13
-<p/>
-<sref ref="[hive.capacity]"/>:<br/>
-(`shrink_to_fit`) p10<br/>
-(`reshape`) p24
-<p/>
-(both of the above functions may potentially relocate existing elements
-from one block to erased element locations in another)
-<p/>
-<sref ref="[hive.cons]"/>:<br/>
-(<tt>operator= &amp;</tt>) p27<br/>
-(<tt>operator= &amp;&amp;</tt>) p31
-<p/>
-(move assignment will switch to moving individual elements where
-allocators are not equal - and in the case of non-trivial/allocating
-types, move-assigning to existing elements in the source may be beneficial)
-<p/>
-In addition, if we were to support bitset-stacking approaches these also
-effect functions which erase individual elements. This includes:
-<p/>
-<sref ref="[hive.modifiers]"/>:<br/>
-(`erase`) p16
-<p/>
-<sref ref="[hive.operations]"/>:<br/>
-(`unique`) p11
-</p>
 
-<blockquote class="note">
-<p>
-This issue has some overlap to LWG <iref ref="4323"/>, and it would 
-affect the outcome wording of that issue for `unique`.
-</p>
-</blockquote>
-</discussion>
-
-<resolution>
+<superseded>
 <p>
 This wording is relative to <paper num="N5014"/>.
 </p>
@@ -342,6 +304,59 @@ at worst <tt>&#x1d4aa;(log n)</tt> in the capacity of each block containing the
 
 </li>
 
+</ol>
+</superseded>
+
+<note>2025-09-26; Matt comments and provides improved wording</note>
+<p>
+Past LWG/LEWG telecon discussion around this topic concluded that because elements are not involved, 
+and the logarithmic action is within the capacity of a block (a fixed number), not the size of the 
+sequence, and the actual performance cost is negligible, that the complexity of these actions are 
+in fact constant. But there is some disagreement on this.
+<p/>
+One possibility is to add additional complexity data to each of the effected functions. This would 
+impact on `emplace`, range `insert`, fill `insert`, `shrink_to_fit`, `reshape`, copy/move 
+assignment operator, `erase` and `unique`. However I feel this is overkill and may confuse 
+implementors as the log(n) complexity is not permitted to involve elements.
+<p/>
+Having looked into it and sought feedback I think a blanket note on <sref ref="[hive.overview]"/> p3 
+would be sufficient, such that the time complexity is limited to "techniques to identify the memory 
+locations of erased elements". Otherwise we need to stay with the previous resolution that this 
+is in fact constant time behaviour.
+</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>The same or different techniques 
+may be utilized to find and re-use these locations during subsequent insertions.</ins> 
+<p/>
+<ins>[<i>Note</i>: The techniques are permitted to be at worst logarithmic in the capacity of the 
+element blocks being inserted into or erased from while maintaining constant-time iteration, to allow 
+latitude for implementation-specific optimizations. &mdash; <i>end note</i>]</ins>
+</p>
+</blockquote>
+
+</li>
+
 </ol>
 </resolution>