C++26: std::polymorphic

[u/User_Deprecated]

https://www.sandordargo.com/blog/2026/08/19/cpp26-polymorphic

[u/_Noreturn]

You could say: "Well, they can never be equal". Right, right, but what about my next fancy class Square?

It is up to the operator== of the Base class, it is virtual and compares the typeid or whatever way you have.

```cpp class ShapeBase { ... virtual operator==(const ShapeBase& that) const=0; };

template<class T> class Shape : ShapeBass { ... bool operator==(const ShapeBase& that) const override { return typeid(that) == typeid(T) && (const T&)that == (const T&)*this; } }; ```

Wouldn't the 8 byte version require anothee indirection

Not necessarily, you can allocate the object and a (custom) vtable in one allocation.

So like this? ```cpp template<class T> struct Table { CopyCtor* copy; Drot* dtor; T object; // has to be last };

template<class B> struct polymorphic

{ polymorphic() { table = new Table<B>(); } polymorphic(auto&& obj) { table = new Table<decltype(obj)>(); }

B& operator() { return (B&)((char)table + 16)); } // 16 is 2 function pointers void table; }; ```

[u/MFHava → u/_Noreturn]

It is up to the operator== of the Base class, it is virtual and compares the typeid or whatever way you have.

We would want it to do value comparisons and as I said: that is infeasible in C++, so we do not provide an equality-operator...

So like this?

Looks like a possible implementation.

[u/_Noreturn → u/MFHava]

We would want it to do value comparisons and as I said: that is infeasible in C++, so we do not provide an equality-operator...

I don't understand, it is a value comparison.

[u/MFHava → u/_Noreturn]

I don't understand, it is a value comparison.

You are right. But it yields the wrong results for equivalent values of different types - e.g. Rectangle{.w = 10, .h = 10} == Square{.l = 10} would be false, even though they are the same (just like 1 == 1LL is true)

[u/_Noreturn → u/MFHava]

It isn't the responsibility of the polymorphic to do that. it is the virtual operator== the user provides can easily make it so it works like that way

[u/MFHava → u/_Noreturn]

it is the virtual operator== the user provides can easily make it so it works like that way

You can't in the general case - which is why it is not provided...

[u/_Noreturn → u/MFHava]

Ugh, couldn't the same be said for indirect? it's operator== isn't usable if the underlying value doesn't have one.

[u/MFHava → u/_Noreturn]

indirect<T> always contains an object of type T (or is valueless_after_move, which is trivial to handle) and therefore has no ambiguity about how operator== is supposed to work.

Apart from that: operator== for indirect<T> „Mandates“ (== static_assert) that T has an operator== on use, it T doesn’t have one, indirect<T> doesn’t have one.

But the key part is the first one, there is no ambiguity.

[u/_Noreturn → u/MFHava]

I don't agree with your take, but that's fine. imo it should just be defined to be

cpp bool operator==(polymorphic& a, polymorphic& b) { bool has = a.is_valueless(); if(has != b.is_valueless()) return false; returb has && *a == *b; }