Document number: | P0899R1 |
Date: | 2018-11-08 |
Project: | C++ Programming Language, Library Working Group |
Reply-to: |
Casey Carter <Casey@Carter.net> |
LWG 3016 proposes adding the phrase:
It is implementation-defined whether over-aligned types are supported (6.6.5 [basic.align]).
to the specification of std::optional
in [optional.optional]/1. This proposal:
Absent explicit specification otherwise, it’s reasonable to assume that the requirements of the core language apply to entities specified in the Standard Library. Specifically, the requirements in [basic.align] apply to the library portions of the standard. Hence, given the specification of a class template S
:
There is no need to explicitly specify that [basic.align]/3 applies to “internal”: if T
is an over-aligned type, then support for S<T>
is implementation-defined. Similarly, the specification of optional<T>
in [optional.optional]/1:
… When an instance of
optional<T>
contains a value, it means that an object of typeT
, referred to as the optional object’s contained value, is allocated within the storage of the optional object. Implementations are not permitted to use additional storage, such as dynamic memory, to allocate its contained value. The contained value shall be allocated in a region of theoptional<T>
storage suitably aligned for the typeT
. …
says that the contained value is “suitably aligned” for the type T
. Albeit the term “suitably aligned” is not specified, I believe the only reasonable interpretation is that the contained value is aligned accordingly for a subobject of type T
- just as in the first case of an exposition-only member - in an implementation-defined manner in accordance with [basic.align]/3.
Adding redundant text to [optional.optional]/1 would obviously not improve the quality of the Standard; if LWG agrees with the rationale provided herein, then LWG3016 should be closed as NAD.
In addition to closing LWG 3016 as NAD, it behooves us to remove similar redundant wording from the rest of the Standard Library specification. Wording relative to N4713.
Change [variant.variant]/1 as follows:
1 Any instance of
variant
at any given time either holds a value of one of its alternative types, or it holds no value. When an instance ofvariant
holds a value of alternative typeT
, it means that a value of typeT
, referred to as thevariant
object’s contained value, is allocated within the storage of thevariant
object. Implementations are not permitted to use additional storage, such as dynamic memory, to allocate the contained value. The contained value shall be allocated in a region of thevariant
storage suitably aligned for all types inTypes...
.It is implementation-defined whether over-aligned types are supported.
Change [meta.trans.other] as follows (Note that striking this sentence also resolves Editorial issue #1757 which is currently assigned LWG status):
[…]
2
It is implementation-defined whether any extended alignment is supported ([basic.align]).[…]