Am Mi., 15. Apr. 2020 um 17:58 Uhr schrieb Ville Voutilainen
<ville.voutilainen_at_[hidden]>:
>
> On Wed, 15 Apr 2020 at 18:43, Daniel Krügler via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
> >
> > Am Mi., 15. Apr. 2020 um 16:13 Uhr schrieb Edward Diener via
> > Std-Discussion <std-discussion_at_[hidden]>:
> > >
> > > In C++17 if a std::hash specialization for a key is not provided and is
> > > therefore considered a disabled specialization, is it a compiler error
> > > if an unordered associate container is instantiated with that key ?
> > >
> > > As an example:
> > >
> > > struct MyStruct
> > > {
> > > int x;
> > > long y;
> > > MyStruct(int a, long b) : x(a), y(b) {}
> > > };
> > >
> > > /* No std::hash specialization is provided for MyStruct */
> > >
> > > MyStruct my1(1,2);
> > >
> > > std::unordered_set<MyStruct> oname;
> > > oname.insert(my1);
> > >
> > > Should the code cause a compilation error in C++17 and above ?
>
> It should cause a compilation error in C++11 and above.
>
> >
> > The standard says for a disabled specialization:
> >
> > "these values are false: is_default_constructible_v<H>,
> > is_copy_constructible_v<H>, is_move_constructible_v<H>,
> > is_copy_assignable_v<H>, and is_move_assignable_v<H>. Disabled
> > specializations of hash are not function object types (23.14)."
> >
> > For unordered associative containers, C++17 imposes the requirement
> >
> > "Hash shall be a unary function
> > object type such that the
> > expression hf(k) has type
> > size_t."
> >
> > For the default constructor the requirements
> >
> > "hasher and
> > key_equal are
> > DefaultConstructible."
> >
> > are imposed.
> >
> > Technically these are pre-conditions whose violation would lead to UB.
> > But given the above mentioned characteristics of disabled hash
> > specializations I would expect sane implementations to make the code
> > ill-formed, e.g. when the constructor of the set is invoked or the
> > when insert is called.
>
> 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.

That being said: I would be seriously surprised if someone can point
to an implementation that doesn't diagnose this.

- Daniel