Re: [boost] [hash][array][stacktrace][type_index] Adding noexcept to hash

On 4 December 2017 at 09:22, Richard Hodges via Boost wrote:

On 4 December 2017 at 09:57, Daniel James via Boost wrote:

...

On 4 December 2017 at 06:54, Richard Hodges via Boost wrote:

...

Adding a noexcept specification (i.e. making an interface more restrictive) sounds like a breaking change to me. Although it's the correct thing to do, surely anyone who has an override of hash_range in their code will be affected?

It isn't a member function, so there's no way to override it. The customization point is a call to hash_value via argument dependent lookup. The noexcept specifiers are going to be conditional on whether the iterators and hash functions are noexcept, so if an overload doesn't have a noexcept specification, then hash_range for that value is going to be effectively noexcept(false) and will still be compatible.

Forgive me. I of course meant overload.

Overloads can use a different noexcept specification, but users shouldn't really be overloading hash_range anyway.

What I mean is that I assume the intention is to make any hashable thing noexcept-hashable? That seems sensible to me, since the hash of an object is an invariant for any given state of the object in any one program run.

The intention is make hashing noexcept only when it's known to be. That means that if the iterators or the overload of hash_value aren't noexcept, then the hash function won't be. Perhaps this is excessively over-generalized, but that's what you get for following the standard library.