uploaded current status

doc/unordered/compliance.adoc

@@ -5,13 +5,15 @@
 
 :cpp: C++
 
+== Closed-addressing containers: unordered_[multi]set, unordered_[multi]map
+
 The intent of Boost.Unordered is to implement a close (but imperfect)
 implementation of the {cpp}17 standard, that will work with {cpp}98 upwards.
 The wide compatibility does mean some comprimises have to be made.
 With a compiler and library that fully support {cpp}11, the differences should
 be minor.
 
-== Move emulation
+=== Move emulation
 
 Support for move semantics is implemented using Boost.Move. If rvalue
 references are available it will use them, but if not it uses a close,
@@ -23,7 +25,7 @@ but imperfect emulation. On such compilers:
 * The containers themselves are not movable.
 * Argument forwarding is not perfect.
 
-== Use of allocators
+=== Use of allocators
 
 {cpp}11 introduced a new allocator system. It's backwards compatible due to
 the lax requirements for allocators in the old standard, but might need
@@ -56,7 +58,7 @@ Due to imperfect move emulation, some assignments might check
 `propagate_on_container_copy_assignment` on some compilers and
 `propagate_on_container_move_assignment` on others.
 
-== Construction/Destruction using allocators
+=== Construction/Destruction using allocators
 
 The following support is required for full use of {cpp}11 style
 construction/destruction:
@@ -76,7 +78,7 @@ constructing a `std::pair` using `boost::tuple` (see <<compliance_pairs,below>>)
 When support is not available `allocator_traits::construct` and
 `allocator_traits::destroy` are never called.
 
-== Pointer Traits
+=== Pointer Traits
 
 `pointer_traits` aren't used. Instead, pointer types are obtained from
 rebound allocators, this can cause problems if the allocator can't be
@@ -84,7 +86,7 @@ used with incomplete types. If `const_pointer` is not defined in the
 allocator, `boost::pointer_to_other<pointer, const value_type>::type`
 is used to obtain a const pointer.
 
-== Pairs
+=== Pairs
 
 Since the containers use `std::pair` they're limited to the version
 from the current standard library. But since {cpp}11 ``std::pair``'s
@@ -105,7 +107,7 @@ Older drafts of the standard also supported variadic constructors
 for `std::pair`, where the first argument would be used for the
 first part of the pair, and the remaining for the second part.
 
-== Miscellaneous
+=== Miscellaneous
 
 When swapping, `Pred` and `Hash` are not currently swapped by calling
 `swap`, their copy constructors are used. As a consequence when swapping
@@ -114,3 +116,28 @@ an exception may be thrown from their copy constructor.
 Variadic constructor arguments for `emplace` are only used when both
 rvalue references and variadic template parameters are available.
 Otherwise `emplace` can only take up to 10 constructors arguments.
+
+== Open-addressing containers: unordered_flat_set, unordered_flat_map
+
+The C++ standard does not currently provide any open-addressing container
+specification to adhere to, so `boost::unordered_flat_set` and
+`boost::unordered_flat_map` take inspiration from `std::unordered_set` and
+`std::unordered_map`, respectively, and depart from their interface where
+convenient or as dictated by their internal data structure, which is
+radically different from that imposed by the standard (closed addressing, node based).
+
+`unordered_flat_set` and `unordered_flat_map` only work with reasonably
+compliant C++11 (or later) compilers. Language-level features such as move semantics
+and variadic template parameters are then not emulated. 
+`unordered_flat_set` and `unordered_flat_map` are fully https://en.cppreference.com/w/cpp/named_req/AllocatorAwareContainer[AllocatorAware^].
+
+The main differences with C++ unordered associative containers are:
+
+* `value_type` must be move-constructible.
+* Pointer stability is not kept under rehashing.
+* `begin()` is not constant-time.
+* `erase(iterator)` returns `void` instead of an iterator to the following element.
+* There is no API for bucket handling (except `bucket_count`) or node extraction/insertion.
+* The maximum load factor of the container is managed internally and can't be set by the user. The maximum load,
+exposed through the public function `max_load`, can not increase monotonically with the number of erasures.
+