On Sunday, 5 April 2026 15:44:00 Pacific Daylight Time Muneem via Std-Proposals
wrote:
> Thanks for your feedback ❤️❤️❤️🙂
> here is a way to make this type safe, which is unless the index is
> constexpr, the return value is an object like std::variant. Your
> abstraction is as I said fragile:
> 1.slicing even if you provide a virtual clone function, so my technique is
> more type safe.

I don't see how you're solving this problem. There are two issues that cause
object slicing: first, it's the calling of a function to implement it. This is
easy to do with a virtual function, so a solved problem, but different from
copy/move semantics.

Second and most importantly: the destination memory area must be of sufficient
size to accommodate any of the runtime full objects, which by definition cannot
be known at compile time. You are not addressing this problem. And if you come
up with a solution for it, then it is also available for the case of calling a
virtual function.

And again: what do virtual functions and object slicing have to do with
anything?

> 2.By gurrentied optimizations, I meant, the (subscript) operation is to be
> completely inlined if the index is constexpr. This would again help someone
> avoid having two define two functions, one constexpr and one runtime
> polymorphic (virtual).

Same as std::variant then.

> 3. You can't pass storage[index] (in your example) to a function, expecting
> the right overload to be called(in your example that function would have
> different overloads for different "flavors"), which leads to all functions
> possible be virtual members, and for operators or functions meant to return
> a copy *this, we still have an issue of slicing; virtual members are
> incomplete.

And I don't see how you're solving this problem. This is still the "magic
happens" portion of what you've been trying to convey for a week and it seems
no one understands.

You seem to be saying that one needs to have an overload for each of the
possible types, but your solution removes this need. How?

> 4.the user can't handle storage[index] in overloads, for example, there
> might be a overload accepting storage&, but there can't be an overload
> accepting storage& used for runtime polymorphism. This is an issue because
> we are mixing references with polymorphism.
> 5. How is it not type safe? How are virtual clone functions more type safe?

We don't know if it is type-safe, because we can't tell what the type is and
how the compiler can reason anything at compile time to prove safety, because
we don't understand what you're proposing.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.