This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.
Section: 24.2.7 [associative.reqmts] Status: C++14 Submitter: Daniel Krügler Opened: 2013-09-24 Last modified: 2016-01-28
Priority: 1
View other active issues in [associative.reqmts].
View all other issues in [associative.reqmts].
View all issues with C++14 status.
Discussion:
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.[2013-09-24 Daniel provides resolution suggestion]
[2013-09-25 Chicago]
Daniel's wording is good, advance to Immediate to respond to NB comment.
[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]:
Change 24.2.7 [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, […]Change 24.2.7 [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.
[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".
[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.
Proposed resolution:
This wording is relative to N3797.
Change 24.2.7 [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_transparentexistsis valid and denotes a type (13.10.3 [temp.deduct]), […]
Change 24.2.7 [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_transparentexistsis valid and denotes a type (13.10.3 [temp.deduct]).