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.
// 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?
static_cast<void(std::string_view&&)>(throw_runtime)({std::move(msg)});//XXX: We may have to rename the above function (and make it [[internal]], or refactor to make it a private method of a function-object class `throw_runtime` to avoid ambiguations when constexpr-context calls it with the exact typed argument `std::string_view&&`... Maybe... I'm not really sure.
}
__builtin_unreachable();
}
// Returns an anonymous union with inavtive field: `T value` and active field `assume init` (no unique address).