Dana Jansens

These errors are resolved for me by enabling the `used_linker` feature. I did not need to add any extra `#[used]` attr on to the static slice variable itself. Example successful...

## First, an optimization for pointer/reference T: What we can do for `Result` in general, where `alignof(T) >= 4`, is use the lowest 2 bits to store the state: https://source.chromium.org/chromium/chromium/src/+/main:third_party/dawn/src/dawn/common/Result.h;l=129-130;bpv=1;bpt=1?q=f:dawn%20result&ss=chromium...

Hey, you can just send a PR to add the functions and tests. :) Thanks!

Ah yes and the ctors are recursive: ```cpp template constexpr inline TupleStorage(T& value, Us&&... more) noexcept : Super(::sus::forward(more)...), value(::sus::mem::addressof(value)) {} ``` libc++ does some funky multi-inheritance thing which I didn't...

See https://github.com/chromium/libboring/pull/18/files#diff-31d7ab4fc4540dd54d161f7a3f242b5ee5b134983b2d7b3e1beaeba496206c6e for the original version.

We do need to use std::allocator in constexpr contexts, so the default allocator will either need to be std::allocator or our own allocator API that defers to it. But I...

https://stackoverflow.com/questions/27471053/example-usage-of-propagate-on-container-move-assignment for how to handle std::allocator_traits which is a big wow. I think we can and should consider restricting allocators in a concept to: ```cpp static_assert( std::allocator_traits::propagate_on_container_move_assignment::value); static_assert( !std::allocator_traits::propagate_on_container_copy_assignment::value); ```...

https://github.com/Voultapher/sort-research-rs/blob/main/writeup/sort_safety/text.md#safety-vs-performance-a-case-study-of-c-c-and-rust-sort-implementations

From this we can see for safety and performance we can just port the rust sort algorithms over directly.

Current plan is to put everything unstable into a sus_unstable namespace and then in all the lib headers do ```cpp namespace sus { using namespace ::sus_unstable; } ``` I will...