Hello,

so recently I got exited because Visual Studio added support for heterogenous lookup in unordered containers. I've been using a pretty messy "maybe-owning" string-hack to guarantee lookup in a container by string doesn't inquire unnecessary copies, and I was glad to be able to remove that.

Then I found out: Het. lookup is only supported on a few functions:

find, equal_range, count, contains

uh, what about
at, erase, extract?

I understand why the possibly inserting functions cannot be called without constructing an element of key_type, but I don't see any reason why those 3 mentioned about cannot benefit from that.

Does anyone here?
(Paper is http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0919r1.html)

I don't really see a reason why they would need to support the interface. The iterator returned by 'find' can be passed to overloads of 'erase' and 'extract', and 'at' just adds some exception-safe shorthand around accessing mapped values directly. But otherwise there's nothing preventing you from getting the benefits of heterogeneous lookup.

Zipster said:
I don't really see a reason why they would need to support the interface. The iterator returned by 'find' can be passed to overloads of 'erase' and 'extract', and 'at' just adds some exception-safe shorthand around accessing mapped values directly. But otherwise there's nothing preventing you from getting the benefits of heterogeneous lookup.

I don't like that it makes the code more complicated though.

Ok, erase/extract is only half-bad:

map.erase(key);
// vs
map.erase(map.find(key));

But replacing my ats?

return map.at(key);
// vs
const auto itr = map.find(key);
assert(itr != map.end());
return itr->second;

Its not even that I need the exception-safety, but I definately need to know that when I call at the element actually exists, and don't just get garbage-memory access. I can write a free function to wrap that, sure. I just don't like it.

I get your point, its "you have all the tools needed to perform the tasks you need to do", I'd argue though that it creates a discrepancy in ease of use that is not really acceptable. Use direct-key lookup or complicate your code.