LWG Poll 5: P1460R1 Mandating the Standard Library: Clause 20 - Utilities library #3788
Conversation
|
|
||
| \pnum | ||
| \constraints | ||
| \tcode{is_constructible_v<$\tcode{T}_I$, Args...>} is \tcode{true}. |
There was a problem hiding this comment.
Constraints: come before Mandates:.
There was a problem hiding this comment.
As above, this is as requested by the wording paper.
There was a problem hiding this comment.
... but this wording is meaningless. We can't have a Mandates: on a property of T_I if we only have a Constraints: that I is in-bounds. That doesn't make any sense.
I've mailed LWG to ask what they want here. I propose we leave the wording alone (and don't reorder these elements) for now -- reordering these elements obscures the likely intent (for the Mandates: to apply before overload resolution).
|
|
||
| \pnum | ||
| \constraints | ||
| \tcode{is_constructible_v<$\tcode{T}_I$, initializer_list<U>\&, Args...>} is \tcode{true}. |
There was a problem hiding this comment.
Constraints: come before Mandates:.
There was a problem hiding this comment.
As above, this is as requested by the wording paper.
| \tcode{T} is \tcode{U[]} and \tcode{Y(*)[]} is convertible to \tcode{T*}. | ||
| When \tcode{T} is not an array type, | ||
| the expression \tcode{delete p} is well-formed and | ||
| \tcode{Y*} is convertible to \tcode{T*}. |
There was a problem hiding this comment.
Constraints: come before Mandates:.
There was a problem hiding this comment.
I'm concerned this will change the presumptive intent. Consider:
#include <memory>
struct Base; struct Derived;
bool k = requires (Derived *p) { std::shared_ptr<Base*>(p); };
Does this violate a Mandates or a Constraints? (Put another way: is the above program guaranteed to be well-formed, or could it result in a non-immediate-context error?)
With the current order of elements, the suggestion (albeit a flawed one) is that the program can be rejected. Reversing the order of elements removes the suggestion that the Mandates: could somehow mysteriously apply prior to overload resolution, requiring that example to be accepted.
| \requires | ||
| \tcode{alignment} shall be a power of two. | ||
| \expects | ||
| \tcode{alignment} is a power of two. |
There was a problem hiding this comment.
| \tcode{alignment} is a power of two. | |
| \tcode{has_single_bit(alignment)} is \tcode{true}. |
There was a problem hiding this comment.
We're trying to express the requirement that the alignment be a power of 2. We get no benefit from circumlocution via a (now-terribly-named) library function.
We should generally prefer plain simple descriptions, not description-by-mechanism, where possible (for example, requirements like "is_same_v<T, U> is false" are uniformly awful, and requiring "T is not the same type as U" would be much clearer and simpler).
jensmaurer
added
the
changes requested
zygoloid
removed
the
changes requested
zygoloid
force-pushed
the
motions-2020-02-lwg-5
branch
from
e77f2bf
to
bdaf776
Compare
Ignored requested change from "Requires:" to "Mandates:" for tuple(tuple&&) constructor. This has already been replaced with "Constraints:" by LWG 2899.
zygoloid
force-pushed
the
motions-2020-02-lwg-5
branch
from
bdaf776
to
4e38518
Compare
|
And if it weren't for Annex D, we could even get rid of the Requires element from the library specification! |
Fixes #3707.
Also fixes cplusplus/papers#726.