What aggregate-paren-init gave us in the standard library

Abstract

This paper is not a proposal. It's a report of what standard library facilities now work with aggregates automatically, whereas they didn't work before aggregates were initializable from parenthesized parameter lists. The report in this paper may be incomplete, but hopefully should be correct.

The material in the paper is based on an exercise of adding tests for aggregate-paren-init to libstdc++.

Underlying plumbing

The bedrock of all of this is that now std::is_constructible gives us the right answer for whether an aggregate is initializable from a parenthesized argument list.

The next plumbing bits are std::allocator_traits<T>::construct and std::construct_at.

Now we have the building blocks in hand, and the rest just falls out.

Emplace and in-place construction in std::any

I.e. any::emplace, any(in_place_type_t<T>, ...).

Emplace and in-place construction in std::optional

I.e. optional::emplace, optional(in_place_t, ...).

Emplace and in-place-type and in-place-index construction in variant

Pretty similar to any and optional.

The main motivation for all this, std::make_unique

Imagine that, THE recommended way to create objects with dynamic storage duration now works with more types.

Its best friend, std::make_shared

Imagine that, the recommended way to create shared objects now works with more types.

Piecewise construction in std::pair

You probably shouldn't be calling that in your code, though.. ..as it should be just an implementation detail of the following item.

The uses-allocator utilities, std::make_obj_using_allocator and std::uninitialized_construct_using_allocator

Kinda nice that your allocator-aware types work even with aggregate element types.

Emplace in containers

• deque::emplace_front, deque::emplace_back
• forward_list::emplace_front, forward_list::emplace_after
• list::emplace_front, list::emplace_back, list::emplace
• map::emplace, map::try_emplace
• set::emplace
• multimap::emplace
• multiset::emplace
• priority_queue::emplace
• queue::emplace
• stack::emplace
• unordered_map::emplace, unordered_map::try_emplace
• unordered_set::emplace
• unordered_multimap::emplace
• unordered_multiset::emplace
• vector::emplace, vector::emplace_back

Yay, the facility that can construct container elements without copying or moving them can now also construct aggregate elements.

Making these things work required zero effort in the library implementation...

..now that we made a language fix that made the library facilities Just Work.