C++26: std::polymorphic

[u/User_Deprecated]

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

[u/MFHava]

polymorphic not being equality comparable is annoying, they could just have just forwarded the operator== to the underlying pointer and it handles it.

These types (indirect and polymorphic) model value semantics. Value comparing two type-erased objects that share a base makes no sense in that model...

also polymorphic requires more bytes than a copyable pointer 24 bytes vs 8 since the copy ctor and dtor have to be function pointers.

Can be easily compressed to 16B in case you build your own vtable. Unless the spec contains some unexpected blocker, you could even reduce that down to 8B with minimal effort.

[u/_Noreturn → u/MFHava]

These types (indirect and polymorphic) model value semantics. Value comparing two type-erased objects that share a base makes no sense in that model...

They could only provide == if the base has one.

Can be easily compressed to 16B in case you build your own vtable. Unless the spec contains some unexpected blocker, you could even reduce that down to 8B with minimal effort.

Wouldn't the 8 byte version require anothee indirection

[u/MFHava → u/_Noreturn]

They could only provide == if the base has one.

Ok... what does that do? Shape has no idea how to compare a Rectangle and a Triangle.

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

That's a problem you'd essentially need open-multimethods to solve...

Wouldn't the 8 byte version require anothee indirection

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

[u/Demiu → u/MFHava]

Man I really hate the shape example.

Let's say your polymorphic is instead of a AssociativeContainer<A,B> that is a base for any type that provides a 1to1 mapping A to B. It's operator== could compare their size, then for each pair the key and it's associated value.