Proposed resolution:

This wording is relative to N3797.

1. Change [associative.reqmts] p8 as indicated:

   -8- In Table 102, X denotes an associative container class, a denotes a value of X, a_uniq denotes a value of X when X supports unique keys, a_eq denotes a value of X when X supports multiple keys, a_tran denotes a value of X when the typequalified-id X::key_compare::is_transparent existsis valid and denotes a type ([temp.deduct]), […]

2. Change [associative.reqmts] p13 as indicated:

   The member function templates find, count, lower_bound, upper_bound, and equal_range shall not participate in overload resolution unless the typequalified-id Compare::is_transparent existsis valid and denotes a type ([temp.deduct]).

[ 2014-02-12 Issaquah: Move to Immediate ]

STL: This uses "valid type", which is a Phrase Of Power in Core, and Daniel has a citation for the term.

Jonathan: It's nice to rely on Core.

[ 2014-02-10 Daniel comments provides alternative wording ]

I could confirm that my previous concerns were unwarranted, because they turned out to be due to a compiler-bug. Nonetheless I would suggest to replace the previously suggested replication of core-wording situations (access, ambiguity, hidden) by a single more robust phrase based on "valid type".

[ 2013-09-26 Chicago ]

Moved back to Review as Daniel would like another look at the words, and to confirm implementability.

Previous resolution from Daniel [SUPERSEDED]:

1. Change [associative.reqmts] p8 as indicated:

   -8- In Table 102, X denotes an associative container class, a denotes a value of X, a_uniq denotes a value of X when X supports unique keys, a_eq denotes a value of X when X supports multiple keys, a_tran denotes a value of X when thea publicly accessible type X::key_compare::is_transparent exists whose name is unambiguous and not hidden, […]

2. Change [associative.reqmts] p13 as indicated:

   The member function templates find, count, lower_bound, upper_bound, and equal_range shall not participate in overload resolution unless thea publicly accessible type Compare::is_transparent exists whose name is unambiguous and not hidden.

[ 2013-09-25 Chicago ]

Daniel's wording is good, advance to Immediate to respond to NB comment.

[ 2013-09-24 Daniel provides resolution suggestion ]

Addresses ES 16

The condition "X::key_compare::is_transparent exists" does not specify that the type be publicly accessible.

Consider the public accessibility of X::key_compare::is_transparent and whether its potential inaccessibility should be banned for a compliant key_compare type.