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: 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]:

> 1. 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 a publicly accessible type `X::key_compare::is_transparent` exists whose name is unambiguous and not hidden, […]

> 2. 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 a 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 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 type qualified-id `X::key_compare::is_transparent` exists is valid and denotes a type (13.10.3 [temp.deduct]), […]

2. 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 type qualified-id `Compare::is_transparent` exists is valid and denotes a type (13.10.3 [temp.deduct]).