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

4305. Missing user requirements on type_order template

Section: 17.12.7 [compare.type] Status: New Submitter: Daniel Krügler Opened: 2025-07-27 Last modified: 2025-07-27

Priority: Not Prioritized

View all issues with New status.

Discussion:

The recently approved paper P2830R10 proposes to add the new type_order type traits to 17.12 [cmp] (and thus outside of 21.3 [type.traits]), which has the subtle and most likely unintended effect, that it doesn't fall under the general requirement expressed in 21.3.2 [meta.rqmts] p4,

Unless otherwise specified, the behavior of a program that adds specializations for any of the templates specified in 21.3.2 [meta.rqmts] is undefined.

and so in principle the explicit allowance specified in 16.4.5.2.1 [namespace.std] p2,

Unless explicitly prohibited, a program may add a template specialization for any standard library class template to namespace std […]

holds. So we need to add extra wording to the type_order specification in 17.12.7 [compare.type] to prohibit such program specializations.

This was reported shortly before the Sofia meeting during reflector discussion but seems to be forgotten before the final paper appeared on plenary.

During the reflector discussion two possible ways to solve this issue were pointed out:

  1. The most simple one would mimic the wording in 21.3.2 [meta.rqmts] p4 quoted above.

  2. Instead of introducing just another undefined opportunity to run into undefined behaviour it has been pointed out that we could follow the approach taken by std::initializer_list and make the program ill-formed in this case, as specified in 17.11.2 [initializer.list.syn] p2:

    If an explicit specialization or partial specialization of initializer_list is declared, the program is ill-formed.

Jonathan Wakely responded to the reflector discussion:

I think ill-formed would be better. It shouldn't be difficult for implementations to have special cases that are disallowed.

Given the already existing experience with std::initializer_list the proposed wording below therefore follows the ill-formed program approach.

Proposed resolution:

This wording is relative to this CD preview draft.

  1. Modify 17.12.7 [compare.type] as indicated:

    template<class T, class U>
  struct type_order;

    -2- The name type_order denotes a Cpp17BinaryTypeTrait (21.3.2 [meta.rqmts]) with a base characteristic of integral_constant<strong_ordering, TYPE-ORDER(T, U)>.

    -?- If an explicit specialization or partial specialization of type_order is declared, the program is ill-formed.

    -3- Recommended practice: The order should be lexicographical on parameter-type-lists and template argument lists.