is_always_equal
has slightly inconsistent defaultSection: 16.4.4.6 [allocator.requirements], 20.2.9.2 [allocator.traits.types] Status: C++17 Submitter: Howard Hinnant Opened: 2015-01-18 Last modified: 2017-07-30
Priority: 0
View other active issues in [allocator.requirements].
View all other issues in [allocator.requirements].
View all issues with C++17 status.
Discussion:
Table 28 — "Allocator requirements" says that X::is_always_equal
has a default value
of is_empty<X>
, and this is consistent with the return type description:
Identical to or derived from
true_type
orfalse_type
is_empty<X>
is guaranteed to be derived from either true_type
or false_type
.
So far so good.
typedef see below is_always_equal;Type:
Alloc::is_always_equal
if the qualified-idAlloc::is_always_equal
is valid and denotes a type (14.8.2); otherwiseis_empty<Alloc>::type
.
This is subtly different than what Table 28 says is the default: is_empty<Alloc>::type
is
not is_empty<Alloc>
, but is rather one of true_type
or false_type
.
Change Table 28 to say: is_empty<X>::type
.
Change 20.2.9.2 [allocator.traits.types]/p10:
Type:
Alloc::is_always_equal
if the qualified-idAlloc::is_always_equal
is valid and denotes a type (14.8.2); otherwiseis_empty<Alloc>
.::type
Both options are correct, and I see no reason to prefer one fix over the other. But Table 28 and 20.2.9.2 [allocator.traits.types]/p10 should be consistent with one another.
[2015-02 Cologne]
DK: We should accept the first bullet. GR: Why does is_empty
even have a type member? AM: All type traits
have a type member. I agree with DK's preference for the first type.
Proposed resolution:
This wording is relative to N4296.
Change 16.4.4.6 [allocator.requirements], Table 28 — "Allocator requirements" as presented:
Table 28 — Allocator requirements Expression Return type Assertion/note
pre-/post-conditionDefault …
X::is_always_equal
Identical to or derived
fromtrue_type
or
false_type
[…] is_empty<X>::type
…