This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 24.2.7 [associative.reqmts] Status: NAD Submitter: Tomasz Kamiński Opened: 2014-07-14 Last modified: 2018-06-23
Priority: Not Prioritized
View other active issues in [associative.reqmts].
View all other issues in [associative.reqmts].
View all issues with NAD status.
Discussion:
Currently the heterogeneous lookup in associative container are enabled by presence of is_transparent nested type in the comparator type (24.2.7 [associative.reqmts]). This complicates the definition of call wrapper types that want to define is_transparent if they wrap a callable type that defines is_transparent, and requires the target to be a complete type in cases where an incomplete type would otherwise be ok.
Another problem is that users cannot add the is_transparent member to a third-party comparison type that they do not control, even if they know it supports heterogeneous comparisons. If the associative containers used a trait instead of checking for an is_transparent member type then it would avoid the requirement for complete types, and would allow customization of the trait without modifying the comparator type. This would also be consistent with the traits is_placeholder and is_bind_expression. For backward compatibility with the existing design, the default implementation of the is_transparent trait could depend on the presence of the is_transparent nested type.[2014-11 Urbana]
Move to LEWG
Request for a new metafunction should first be responded to by LEWG.
[2017-02 in Kona, LEWG recommends NAD]
In all discussions of heterogeneous lookup, the entire set of those discussions has been different integer types or string_view vs string. There actually hasn't been an example, that we are aware of, besides those two. -- Could always wrap the third-party type with the comparator? -- Could benefit from a motivating example. -- is_transparent<>, what does it mean?
[2017-06-02 Issues Telecon]
The advantages of changing the API now are not sufficiently clear. We invite a paper presenting motivating examples and more details of the proposed change, but at present consider this Not A Defect.
Resolve as NAD
Proposed resolution: