Proposed resolution:

This wording is relative to N4296.

1. Change [allocator.requirements], Table 28 — "Allocator requirements" as presented:

   Table 28 — Allocator requirements

   Expression	Return type	Assertion/note pre-/post-condition	Default
   …
   X::is_always_equal	Identical to or derived from true_type or false_type	[…]	is_empty<X>::type
   …

[ 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.

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 or false_type

is_empty<X> is guaranteed to be derived from either true_type or false_type. So far so good.

[allocator.traits.types]/p10 says:

typedef see below is_always_equal;

Type: Alloc::is_always_equal if the qualified-id Alloc::is_always_equal is valid and denotes a type (14.8.2); otherwise is_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.

There are two ways to fix this:

1. Change Table 28 to say: is_empty<X>::type.

   or

2. Change [allocator.traits.types]/p10:

   Type: Alloc::is_always_equal if the qualified-id Alloc::is_always_equal is valid and denotes a type (14.8.2); otherwise is_empty<Alloc>::type.

Both options are correct, and I see no reason to prefer one fix over the other. But Table 28 and [allocator.traits.types]/p10 should be consistent with one another.