Make optional<T&> trivially copyable

Contents

1. Introduction

Making operations (at least construction) of optional<T&> trivial is the design intent of [P2988R12]:

3.3 Trivial construction

Construction of optional<T&> should be trivial, because it is straightforward to implement, and optional<T> is trivial. Boost is not.

However, possibly due to a wording oversight, trivial construction is not actually guaranteed, nor is trivial copyability in general. This status quo is inconsistent with the design of optional<T> as a whole: the special members (copy constructor, destructor, etc.) of the primary template are all specified to be trivial if the relevant operations on T are trivial. Therefore, optional<int*> is required to be trivially copyable, unlike optional<int&>.

This issue should be fixed in C++26. A US national body comment by Argonne National Laboratory requesting a solution has been submitted.

1.1. Wording problem

Intuitively, optional<T&> (see [P2988R12]) is a T*, wrapped optional. In fact, the synopsis as specified in ([optional.optional.ref]) is as follows:

If the only non-static data member was val, optional<T&> would be trivially copyable according to [class.prop] definition of "class,trivially copyable". However, the implementation has the freedom to add extra non-static data members, so no trivial operation is strictly guaranteed.

2. Motivation

optional<T&> should be guaranteed to be trivially copyable for the following reasons:

• It makes the design consistent with the primary template optional<T>.
• Trivial copyability is a useful property in this case. It allows storing optional<T&> in a struct whose bytes are copied between processes, uploaded from CPU to GPU (e.g. in CUDA), etc.
• Trivial copyability also makes optional<T&> an implicit-lifetime class type, which makes it possible to starts its lifetime in a union more easily via assignment operator, among other benefits.

3. Design

There are two plausible options to fix the issue of optional<T&>:

1. Simply specify optional<T&> to be trivially copyable.
2. Additionally constrain its layout so it actually becomes a wrapper for a T*.

We propose the second option because trivial copyability is much more useful when the layout of a type is somewhat constrained. This makes it possible to bit_cast<T*>(optional_ref) or to encode optional<T&> using memcpy with some guarantees regarding its layout.

4. Wording

The wording changes are relative to [N5014].

Immediately following [optional.optional.ref.general] paragraph 1, append a paragraph as follows:

5. References