Title
common_type and common_reference have flaws in common
Status
new
Section
[meta.trans.other]
Submitter
Casey Carter

Created on 2018-08-10.00:00:00, last changed 2018-08-22.12:55:05.

Messages

Date: 2018-08-22.12:55:05

Proposed resolution:

This wording is relative to N4762.

  • Modify [meta.trans.other] p5 as follows:

    -5- Note B: Notwithstanding the provisions of [meta.type.synop], and pursuant to [namespace.std], a program may specialize common_type<T1, T2> for types T1 and T2 such that is_same_v<T1, decay_t<T1>> and is_same_v<T2, decay_t<T2>> are each true. [Note: …] Such a specialization need not have a member named type, but if it does, that member shall be a typedef-name for an accessible and unambiguous the qualified-id common_type<T1, T2>::type shall denote a cv-unqualified non-reference type C to which each of the types T1 and T2 is explicitly convertible. Moreover, […]

  • Modify [meta.trans.other] p7 similarly:

    -7- Note D: Notwithstanding the provisions of [meta.type.synop], and pursuant to [namespace.std], a program may partially specialize basic_common_reference<T, U, TQual, UQual> for types T and U such that is_same_v<T, decay_t<T>> and is_same_v<U, decay_t<U>> are each true. [Note: …] Such a specialization need not have a member named type, but if it does, that member shall be a typedef-name for an accessible and unambiguous the qualified-id basic_common_reference<T, U, TQual, UQual>::type shall denote a cv-unqualified non-reference type C to which each of the types TQual<T> and UQual<U> is convertible. Moreover, […]

Date: 2018-08-22.12:55:05

[ 2018-08 Batavia Monday issue prioritization ]

Priority set to 3

Date: 2018-08-10.00:00:00

[meta.trans.other] p5 characterizes the requirements for program-defined specializations of common_type with the sentence:

Such a specialization need not have a member named type, but if it does, that member shall be a typedef-name for an accessible and unambiguous cv-unqualified non-reference type C to which each of the types T1 and T2 is explicitly convertible.

This sentence - which [meta.trans.other] p7 largely duplicates to specify requirements on program-defined specializations of basic_common_reference - has two problems:

  1. The grammar term "typedef-name" is overconstraining; there's no reason to prefer a typedef-name here to an actual type, and

  2. "accessible" and "unambiguous" are not properties of types, they are properties of names and base classes.

  3. While we're here, we may as well strike the unused name C which both Note B and Note D define for the type denoted by type.

History
Date User Action Args
2018-08-22 12:55:05adminsetmessages: + msg10063
2018-08-13 22:38:46adminsetmessages: + msg10031
2018-08-10 00:00:00admincreate