constexprstd::array<T,N>&&/*XXX: <- Is returning an rvalue-ref here acceptible? When is `array` dropped here? Does the caller actuall drop it or the std::move() in here...? We aren't actually assigning the move to anything at all, we're just working through rvalue-refs, so it *should* be fine...??? Fuck this language honestly... */make_sized(std::unique_ptr<PolyArray<T>>&&array){
//TODO: Overload case for `unique_ptr<T, D>` for `deleter` to apply (and contain) `D()` on back_cast()ed pointer T* instead of assuming default `delete`.
structdeleterfinal/*: public ErasedTypeDeleter XXX <- Is this useful, for unerasing the type, maybe?*/{
/// Base class which is used to store the layout of Box<T>'s allocated memory. Intended for use to determine if a certain `T`'s `this` pointer is inside a `Box<T>` or not.
static_assert(util::shares_layout<Box<_Complexdouble>,_Complexdouble*>,"Invalid Box<T> memory layout: More than just T*");
static_assert(util::shares_layout<Box<_Complexdouble>,std::unique_ptr<_Complexdouble>>,"Invalid Box<T> memory layout: More than just std::unique_ptr<T>");
}//TODO: Overload for `const&` that does the type check *before* the copy allocation.
#if 0
template<typenameT,typenameR/*XXX: Maybe remove this, and put the requires after the definition, using `auto&& value` instead of `R&& value`*/>requires(std::derived_from<R,T>)
// Throws NullDerefException<?> for first type of `ptr` that is null (if any are).
// If: `All == true`: Instead will always throw `NullDerefException<T...> (all types) if any are, and will not assume every pointer is likely to be non-null.
// XXX: The usage of __COUNTER__ *might* work as wanted if we wrap it in _EO_CONSTANT_VALUE() and take `util::comptime<uint64_t> auto = _EO_CONSTANT_VALUE(__COUNTER__)` as default argument instead. Maybe... I don't know..
constevaluint64_tseed_linear(uint64_tcounter=__COUNTER__)noexcept{returnuint64_t(counter);}//XXX: This is kinda a dumb experiment, the __TIME__ TU-specific seed should be fine, but __COUNTER__ is a token evaluated regardless of calling context, so... Unless it's used before the #include<>, it'll always be the same.
constexprinlineuint64_tlinear_fixed_seed=splitmit64_once(seed_linear());// ODR dependant?? When is __COUNTER__ evaluated? In preprocessing, right? So, before any compilation?
/// Deducable version of `is_empty_pack<typename...>()`
///
/// Can be used as `is_empty_pack(pack...)` instead of the slightly more ugly `is_empty_pack<decltype(pack)...>()` though with (very unlikely, but possible) implications of actually "evaluating" the pack (despite the values themselves are `const&` and never used, they're still passed.)
/// HOWEVER: The latter should likely be preferred, since this function takes possible-nonconstexpr types as arguments, it cannot be immediate like the non-argument taking overload. See below comment for more information on that.
template<typename...A>
[[gnu::const]]//TODO: XXX: This mostly useless function won't mess up overload resolution for `is_empty_pack<types...>()`, right? If it will, either find a way to make sure it comes LAST, or remove it, it's not worth the hassle just so users (i.e. me) can avoid typeing `decltype` for once in my fuckin life... what a stupud keyword name srsl (see static_assert() below.)
andis_empty_pack<>()//XXX: This might also be ambiguous between the type and value one... Eh.... That's actually useful though, so removing this explicit (and pointless) *usage* of the function from the test would be fine if they don't clash in other ways too.