This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
Section: 16.3.2.4 [structure.specifications] Status: Resolved Submitter: Jeffrey Yasskin Opened: 2013-09-03 Last modified: 2020-05-12
Priority: 3
View other active issues in [structure.specifications].
View all other issues in [structure.specifications].
View all issues with Resolved status.
Discussion:
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 16.3.2.4 [structure.specifications]. Daniel: I suggest to name this new specification element for 16.3.2.4 [structure.specifications] as "Template Constraints:" instead, because the mentioned wording form was intentionally provided starting with LWG 1237(i) to give implementations more freedom to realize the concrete constraints. Instead of the originalstd::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.
[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.
[2020-05-10; Reflector discussions]
Resolved by P0788R3 and the Mandating paper series culminating with P1460R1.
Rationale:
Resolved by P0788R3 and finally by P1460R1.Proposed resolution: