[hash][array][stacktrace][type_index] Adding noexcept to hash

Daniel James

1 Dec 2017 1 Dec '17

8:27 p.m.

Hi, I want to add noexcept support to the hash library, but a few libraries (array, stacktrace, type_index, maybe more) forward declare hash_range for themselves, causing errors if I add a noexpect specifier to hash_range. If I move hash_fwd.hpp into the core module, so that it doesn't add a dependency on the functional module, would they be okay with including it from there? thanks, Daniel

Show replies by date

Richard Hodges

4 Dec 4 Dec

6:54 a.m.

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? Isn't it more correct to offer noexcept and noexcept(false) interfaces with the latter being deprecated? On 1 December 2017 at 21:27, Daniel James via Boost wrote:

...

Hi,

I want to add noexcept support to the hash library, but a few libraries (array, stacktrace, type_index, maybe more) forward declare hash_range for themselves, causing errors if I add a noexpect specifier to hash_range. If I move hash_fwd.hpp into the core module, so that it doesn't add a dependency on the functional module, would they be okay with including it from there?

thanks,

Daniel

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

Daniel James

8:57 a.m.

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.

Richard Hodges

9:22 a.m.

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.

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

Daniel James

9:36 a.m.

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.

2549

Age (days ago)

2552

Last active (days ago)

List overview

Download

4 comments

2 participants

participants (2)

Daniel James
Richard Hodges