Rationale:

[ 2020-05-10; Reflector discussions ]

Resolved by P0788R3 and the Mandating paper series culminating with P1460R1.

[ 2019-03-21; Daniel comments ]

Apparently the adoption of P0788R3 at the Rapperswil 2018 meeting has resolved this issue by introduction of the new Constraints: element.

The C++14 CD has 25 sections including the phrase "X shall not participate in overload resolution ...". Most of these uses are double negatives, which are hard to interpret. "shall not ... unless" tends to be the easiest to read, since the condition is true when the function is available, but we also have a lot of "if X is not Y, then Z shall not participate", which actually means "You can call Z if X is Y." The current wording is also clumsy and long-winded. We should find a better and more concise phrasing.

As an initial proposal, I'd suggest using "X is enabled if and only if Y" in prose and adding an "Enabled If: ..." element to [structure.specifications].

Daniel:

I suggest to name this new specification element for [structure.specifications] as "Template Constraints:" instead, because the mentioned wording form was intentionally provided starting with LWG 1237 to give implementations more freedom to realize the concrete constraints. Instead of the original std::enable_if-based specifications we can use better forms of "SFINAE" constraints today and it eases the path to possible language-based constraints in the future.