On 4 December 2017 at 09:57, Daniel James via Boost <boost@lists.boost.org> wrote:
On 4 December 2017 at 06:54, Richard Hodges via Boost <boost@lists.boost.org> 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.
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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost