Some type-completeness constraints of traits are overspecified
Daniel Kr├╝gler

Created on 2017-03-02.00:00:00 last changed 46 months ago


Date: 2020-02-13.15:35:37

[ 2020-02 Prague Thursday issue discussion ]

Two of the issues (2797 and 3022) had been resolved by the acceptance of P1285R0.

Date: 2018-08-22.12:55:05

[ 2018-08 Batavia Monday issue discussion ]

Issues 2797, 2939, 3022, and 3099 are all closely related. Walter to write a paper resolving them.

Date: 2017-03-15.00:00:00

[ 2017-03-04, Kona ]

Set priority to 2. Is related to 2797, but really needs an audit of the type traits.

Date: 2017-03-02.00:00:00

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.

Date User Action Args
2020-02-13 15:35:37adminsetmessages: + msg11069
2018-08-22 12:55:05adminsetmessages: + msg10093
2017-03-14 03:14:09adminsetmessages: + msg9119
2017-03-02 00:00:00admincreate