Created on 2023-05-01.00:00:00 last changed 17 months ago
Proposed resolution:
This wording is relative to N4944.
Change in [meta.unary.prop], Table 47: Type property predicates [tab:meta.unary.prop] the column title "Preconditions" to "Mandates".
Change in [meta.rel], Table 49: Type relationship predicates [tab:meta.rel] the column title "Comments" to "Mandates".
[ 2023-06-12; Varna ]
During the review P2874R1 the group decided to not change the now decided for Preconditions: element in [depr.meta.types] p3 into a Mandates: element but would like to solve this by this issue.
[ 2023-05-24; Reflector poll ]
Set priority to 3 after reflector poll.
See also issue 2939. We should not turn the preconditions into Mandates without fixing them first.
Since we have adopted the Constraints/Mandates/Preconditions form of wording, "preconditions" refer to runtime requirements, not compile-time. As such, the column labeled "preconditions" in Table 47: Type property predicates [tab:meta.unary.prop] would be better labeled as "Mandates".
This is an LWG issue and not editorial, and "Mandates" would require the library to diagnose violations, but after reviewing all traits in this table, I believe that is reasonable. Table 48: Type property queries [tab:meta.unary.prop.query] shows how Mandates: elements can be integrated into the "Value" column if we preferred that approach, but for the number of entries in the first table seems like an aggressive change for consistency. Similarly, for Table 49: Type relationship predicates [tab:meta.rel] the "Comments" column serves as a "Mandates" feature without using that term, so I suggest changing that column title too. The other tables and type traits wording already appear to be adapted to the Mandates wording style.History | |||
---|---|---|---|
Date | User | Action | Args |
2023-06-12 11:51:17 | admin | set | messages: + msg13620 |
2023-05-24 14:33:00 | admin | set | messages: + msg13577 |
2023-05-06 15:41:32 | admin | set | messages: + msg13540 |
2023-05-01 00:00:00 | admin | create |