When a default-initializable type actually isn't -- Kaashif Hymabaccus

The C++ proposal for indirect and polymorphic introduces two new class templates designed to simplify working with dynamically allocated types while retaining value semantics. This post dives into a curious case with polymorphic, exploring why std::default_initializable<polymorphic<T>> evaluates to trueΓÇöeven when polymorphic<T> can't actually be default-initialized in practice.

When a default-initializable type actually isn't

by Kaashif Hymabaccus

From the article:

I was looking at a proposal for adding value-semantic dynamically-allocated types to C++. You can find it here. This proposal adds two class templates, indirect and polymorphic.

The primary use case for this is to make it easier to write correct composite classes. A motivating example can be found through existential types.

Suppose you want a type T which owns (ownership is key) some objects implementing some interfaces. You don't know what concrete types the sub-objects have, and you don't care. You're fine with dynamic dispatch, with the overhead that entails at runtime. You want value semantics, meaning (among other things) copying T copies the sub-objects too.

In Rust, this is expressible through Box<dyn T>, which lets us own objects and perform dynamic dispatch with value semantics. This is what polymorphic will allow in C++, allowing you to avoid hacking around unique_ptr. See the proposal above for more detailed motivation.

 

View the full article