On Wed, 15 Apr 2020 at 19:20, 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.

Right; to clarify, the operations on a disabled hash should SFINAE.
Whether default
construction of a container should is another matter, but at least the
ill-formedness should be
portable. And I thought it must be, because the default constructor of
an unordered_set
is specified to default construct the hasher, so if that's ill-formed,
the default construction
of the unordered_set should presumably also be, Mandates or not.