This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 112c. See for the official list.


2438. Problems in the specification of qualification conversions

Section: 7.3.6  [conv.qual]     Status: open     Submitter: Richard Smith     Date: 2019-08-14
  1. A type has multiple cv-decompositions, and 7.3.6 [conv.qual] paragraph 3 does not say which one to use when determining the cv-combined type. Should this be the longest decomposition that works, i.e., the greatest n for which you can decompose both types? (We used to refer to the cv-qualification signature, which implicitly meant to take the longest decomposition.)

  2. When computing the cv-combined types of two types T1 and T2, if U1 and U2 are different, shouldn't we add const to all layers above that in the type?

  3. cv03 is left unspecified by the wording in paragraph 3.

  4. We are too eager to replace a Pi3 with “array of unknown bound of”. That should only happen if both Pi1 and Pi2 are array types, or we end up not forming a type T3 that is similar to T1. For example, the cv-combined type of int** and const int (*)[], when decomposed with n == 2, is required to be const int (*)[] by the bulleted rules, and that type is not similar to the original T1.

  5. In various places, we have operators that say, “if one operand is of pointer type, apply array-to-pointer conversions, pointer conversions, and qualification conversions to bring the two operands to their composite pointer type,” but that doesn't work, because the definition of composite pointer type can't cope with one operand being a pointer and the other being an array. We either need to define the composite pointer type of a pointer and an array (and, if that's done in terms of computing the cv-combined type, be careful to ensure that computing the cv-combined type actually works in that case) or to perform the array-to-pointer conversion before considering the composite pointer type.