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.

2299. [CD] Effects of inaccessible key_compare::is_transparent type are not clear

Section: 23.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]:

  1. Change 23.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, […]

  2. Change 23.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.

  1. Change 23.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_transparent existsis valid and denotes a type (13.10.3 [temp.deduct]), […]

  2. Change 23.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_transparent existsis valid and denotes a type (13.10.3 [temp.deduct]).