This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++17 status.
Section: 17.2 [support.types] Status: C++17 Submitter: Richard Smith Opened: 2016-05-10 Last modified: 2017-07-30
Priority: 2
View all other issues in [support.types].
View all issues with C++17 status.
Discussion:
Per 17.2 [support.types]/4:
"The macro offsetof(type, member-designator) accepts a restricted set of type arguments in this International Standard. If type is not a standard-layout class (Clause 9), the results are undefined. [...]"
Implementations in practice interpret this as meaning that the program is ill-formed for classes that are not standard-layout, but several implementations allow additional types as an extension (rejected in their "strictly conforming" modes).
It would seem superior to specify that implementation-defined extensions are permitted, and that the implementation must give a correct answer for any type that it chooses to accept.[2016-05 Issues Telecon]
People were worried about the requirement to report errors implied by 'conditionally supported'.
[2016-06 Oulu]
The concern about errors appears to be less severe that we thought. Moving to Ready.
Friday: status to Immediate
Proposed resolution:
This wording is relative to N4582.
Change in 17.2 [support.types]/4:
-4- The macro offsetof(type, member-designator) accepts a restricted set of type arguments in this International Standard.
If type is notUse of the offsetof macro with a type other than a standard-layout class (Clause 9), the results are undefinedis conditionally-supported.193 The expression offsetof(type, member-designator) is never type-dependent (14.6.2.2) and it is value-dependent (14.6.2.3) if and only if type is dependent. The result of applying the offsetof macro to a static data member or a function member is undefined. No operation invoked by the offsetof macro shall throw an exception and noexcept(offsetof(type, member-designator)) shall be true.