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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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 <[hidden email]>
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
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On 4 December 2017 at 06:54, Richard Hodges via Boost
<[hidden email]> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On 4 December 2017 at 09:57, Daniel James via Boost <[hidden email]>
wrote:

> On 4 December 2017 at 06:54, Richard Hodges via Boost
> <[hidden email]> 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
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On 4 December 2017 at 09:22, Richard Hodges via Boost
<[hidden email]> wrote:

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

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