This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

### 3152. `common_type` and `common_reference` have flaws in common

Section: 20.15.8.7 [meta.trans.other] Status: WP Submitter: Casey Carter Opened: 2018-08-10 Last modified: 2021-10-23

Priority: 3

View all other issues in [meta.trans.other].

View all issues with WP status.

Discussion:

20.15.8.7 [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 20.15.8.7 [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`.

[2018-08 Batavia Monday issue prioritization]

Priority set to 3

[2021-06-23; Reflector poll]

Set status to Tentatively Ready after seven votes in favour during reflector poll.

[2021-10-14 Approved at October 2021 virtual plenary. Status changed: Voting → WP.]

Proposed resolution:

This wording is relative to N4762.

1. Modify 20.15.8.7 [meta.trans.other] p5 as follows:

   > -5- Note B: Notwithstanding the provisions of 20.15.3 [meta.type.synop], and pursuant to 16.4.5.2.1 [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, […]

2. Modify 20.15.8.7 [meta.trans.other] p7 similarly:

   > -7- Note D: Notwithstanding the provisions of 20.15.3 [meta.type.synop], and pursuant to 16.4.5.2.1 [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 type `C` to which each of the types `TQual<T>` and `UQual<U>` is convertible. Moreover, […]