Proposed resolution:

This wording is relative to N4582.

1. Change in [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.

[ 2016-06 Oulu ]

The concern about errors appears to be less severe that we thought. Moving to Ready.

Friday: status to Immediate

[ 2016-05 Issues Telecon ]

People were worried about the requirement to report errors implied by 'conditionally supported'.

Per [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.