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

Subject: Re: [boost] [hash][array][stacktrace][type_index] Adding noexcept to hash
From: Daniel James (dnljms_at_[hidden])
Date: 2017-12-04 09:36:07

On 4 December 2017 at 09:22, Richard Hodges via Boost
<boost_at_[hidden]> wrote:
> On 4 December 2017 at 09:57, Daniel James via Boost <boost_at_[hidden]>
> wrote:
>
>> On 4 December 2017 at 06:54, Richard Hodges via Boost
>> <boost_at_[hidden]> 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.