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
> 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
> 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.
STD-DISCUSSION list run by firstname.lastname@example.org
Older Archives on Google Groups