C++ Logo

STD-DISCUSSION

Advanced search

Subject: Re: C++17 std::hash disabled specializations
From: Daniel Krügler (daniel.kruegler_at_[hidden])
Date: 2020-04-15 11:20:28


Am Mi., 15. Apr. 2020 um 18:09 Uhr schrieb Ville Voutilainen
<ville.voutilainen_at_[hidden]>:
>
> On Wed, 15 Apr 2020 at 19:05, Daniel Krügler <daniel.kruegler_at_[hidden]> wrote:
>
> > > I would expect *correct* implementations to make the code ill-formed,
> > > as those operations
> > > are specified to invoke operations of the hash specialization, and
> > > those operations
> > > are ill-formed for a disabled hash.
> >
> > The working paper does not provide this guarantee. Presumably we need
> > another round of "Mandating" papers to realize that.
>
> Then the working paper is broken. The intent behind
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0513r0.pdf
> and its related issues was to make these things ill-formed, portably.
> They are supposed to SFINAE, and any
> potential UB is unacceptable for that goal.

I wouldn't say that the working paper is broken. But the wording that
it contains is insufficient to provide this guarantee. Remember that
the wording in the table requirements of [unord.req] must work for
every Hash function object that it can get (This may not be a
std::hash specialization), therefore it imposed pre-conditions.

If we want the extra-guarantee that disabled hash specializations
*guarantee* a Mandates violation we need extra-wording for this.

- Daniel


STD-DISCUSSION list run by std-discussion-owner@lists.isocpp.org

Older Archives on Google Groups