Title
[CD] Effects of inaccessible key_compare::is_transparent type are not clear
Status
c++14
Section
[associative.reqmts]
Submitter
Daniel Krügler

Created on 2013-09-24.00:00:00 last changed 122 months ago

Messages

Date: 2014-02-13.21:00:33

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]).

Date: 2014-02-12.00:00:00

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

Date: 2014-02-10.00:00:00

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

Date: 2013-09-26.00:00:00

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

Date: 2013-09-25.00:00:00

[ 2013-09-25 Chicago ]

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

Date: 2013-09-24.00:00:00

[ 2013-09-24 Daniel provides resolution suggestion ]

Date: 2013-09-24.00:00:00

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.

History
Date User Action Args
2014-02-27 17:03:20adminsetstatus: wp -> c++14
2014-02-20 13:52:38adminsetstatus: immediate -> wp
2014-02-13 21:00:33adminsetmessages: + msg6847
2014-02-13 21:00:33adminsetstatus: review -> immediate
2014-02-10 21:05:06adminsetmessages: + msg6812
2013-09-27 13:46:44adminsetmessages: + msg6647
2013-09-27 13:46:44adminsetstatus: immediate -> review
2013-09-26 18:26:05adminsetmessages: + msg6640
2013-09-26 18:26:05adminsetstatus: new -> immediate
2013-09-24 23:13:16adminsetmessages: + msg6604
2013-09-24 22:01:37adminsetmessages: + msg6603
2013-09-24 00:00:00admincreate