[...] the key part of a std::unordered_map is const, so the type of std::pair in the hash table (which is what a std::unordered_map is) isn’t std::pair<std::string, int>, it's std::pair <const std::string, int>. But that's not the type declared for the variable p in the loop above. As a result, compilers will strive to find a way to convert std::pair<const std::string, int> objects (i.e., what’s in the hash table) to std::pair<std::string, int> objects (the declared type for p). They’ll succeed by creating a temporary object of the type that p wants to bind to by copying each object in m, then binding the reference p to that temporary object. At the end of each loop iteration, the temporary object will be destroyed. If you wrote this loop, you'd likely be surprised by this behavior, because you'd almost certainly intend to simply bind the reference p to each element in m.

What is the benefit of allowing this implicit conversion? Is there some common use case where the developer would expect / prefer this implicit conversion (rather than getting a compiler error)?

Note that if you used const auto & instead of trying to figure out the correct type yourself, you would avoid the copy and arguably get cleaner code. It would also keep things more generic. For instance what if later you needed to change int to long. Using auto would reduce the amount of code churn.
– Chris BeckAug 28 '17 at 18:31

@ChrisBeck Yup; in fact, this is precisely what Scott Meyers says in the next paragraph. Still, I wanted to understand the reasons the explicit type specification is so error-prone.
– maxAug 30 '17 at 5:52

Which basically boils down your question to why the following code is allowed:

std::pair<std::string, int> p = std::pair<const std::string, int>{};

Note that I dropped the const& part of p, because it isn't relevant. The conversion is the same, the only difference is that the temporary is bound to a reference instead of being copied.

If you're wondering why OP's snippet doesn't work with a non-const reference, the conversion is the reason why. The result of the conversion is a temporary object, and because any change to the temporary will be useless (its lifetime isn't extended and so it is destroyed right after), so the language disallows it.

This is allowed because std::pair has a constructor that enables this conversion.

template< class U1, class U2 >
pair( const pair<U1, U2>& p );

In your case, U1 is deduced as const std::string and U2 as int. It doesn't actually matter what cv qualifiers U1 and U2 have, because p's elements get copied.

If this would also be disallowed, then the case with the zeroes above would also not be allowed, which doesn't really make sense, because you are copying zero, so it shouldn't matter if you can modify it or not, because that is a totally different operation.

If this is allowed, then why would player.pos = treasure; be disallowed, because the only thing that it does is copying? Like above, it shouldn't matter whether you can change the elements of treasure, because you are only copying them.

This is also why you should use auto&& or const auto& for ranged loops (and maybe even in general?) because it can avoid a copy if you're not careful.

This misses the essential point! Have a look at your (correct) translation of the loop! It says: const std::pair<std::string, int>& p (REFERENCE!) the question is not why std::pair<std::string, int> p = std::pair<const std::string, int>{}; is allowed, which is trivially allowed since it makes a copy. Of course copying const to non const is possible! The question is why std::pair<std::string, int>& p = std::pair<const std::string, int>{}; (REFERENCE) is allowed. The answer is: it is not allowed. What am I getting wrong?
– DrSvanHayAug 28 '17 at 0:13

1

@DrSvanHay Well, it is allowed for the exact same reason: The types don't match, so a conversion sequence is searched. I thought the question was why const pair& = pair2{}; is allowed (note the const)?
– Rakete1111Aug 28 '17 at 0:22

Yes, but that is not written in your explanation. Is it? there is neither const nor & in that sentence
– DrSvanHayAug 28 '17 at 0:25

@Rakete1111 I wonder why the copy constructor template< class U1, class U2 > pair( const pair<U1, U2>& p ) is not made explicit. This would still allow copy initialization (and assignment, if desired, through operator=()), while disallowing the implicit conversion which (IMO) is likely to cause errors.
– maxAug 28 '17 at 0:30