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.
Section: 21.3.3 [meta.type.synop] Status: New Submitter: Daniel Krügler Opened: 2017-03-02 Last modified: 2020-02-13
Priority: 2
View other active issues in [meta.type.synop].
View all other issues in [meta.type.synop].
View all issues with New status.
Discussion:
LWG 2797 (RU 2) suggests that certain type-traits should be required to diagnose violations of their pre-conditions. The basic idea is founded and I see no problems for requiring this for the mentioned traits alignment_of or is_base_of, for example. But if we want to require this diagnostics for some other traits, such as is_convertible, is_constructible (and friends), or is_callable (and possibly some others), we really should be sure that our current requirements are OK.
Unfortunately, there exists some cases, where we currently overspecify imposing complete type requirements where they are not actually required. For example, for the following situation the answer of the trait could be given without ever needing the complete type of X:struct X; // Never defined static_assert(std::is_convertible_v<X, const X&>);
Unfortunately we cannot always allow incomplete types, because most type constructions or conversions indeed require a complete type, so generally relaxing the current restrictions is also not an option.
The core language has a solution for this "small" gap of situations, where the response of the compiler might depend on type completeness: Undefined behaviour. So, I believe we need a somewhat more detailled form to express the intend here. Informally, I would suggest that the program should only be ill-formed in the situation described by LWG 2797, if there exists the possibility that the compiler would require complete types for the considered operation. The example shown above, std::is_convertible_v<X, const X&>, would never require the need to complete X, so here no violation should exist. The presented example might seem a tiny one, but the Standard Library type traits are extreme fundamental tools and we should try to not give the impression that an approximate rule of the current type constraints breaks reasonable code. It is correct, that above example has currently undefined behaviour due to the breakage of pre-conditions, therefore this issue suggests to fix the current situation before enforcing a diagnostic for such valid situations.[2017-03-04, Kona]
Set priority to 2. Is related to 2797, but really needs an audit of the type traits.
[2018-08 Batavia Monday issue discussion]
Issues 2797, 2939, 3022, and 3099 are all closely related. Walter to write a paper resolving them.
[2020-02 Prague Thursday issue discussion]
Two of the issues (2797 and 3022) had been resolved by the acceptance of P1285R0.
Proposed resolution: