On Fri, Sep 18, 2020 at 11:12 AM Ville Voutilainen via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> On Fri, 18 Sep 2020 at 16:10, Richard Hodges via Std-Discussion
> > e.g. in the following hypothetical code:
> >
> > {
> > constexpr auto m = hash_map { { "foo" , 1 }, { "bar", 2 } };
> >
> > //use m
> >
> > } // goes out of scope
> >
> > it would be much more likely that a compiler could deduce intent based on language rules rather than what amounts to a library-based workaround.
>
> Based on what?
>
> >Furthermore, in that particular case the hash function could,as an implementation QOL improvement, be optimised at compile time to be a perfect hash. Performing this as part of a library solution is not trivial.
>
> Really? Based on what?

I think what he's trying to say is that, because this particular
`unordered_map` object is known by the compiler to be constexpr, the
compiler could hypothetically override the hash function and use a
perfect hashing algorithm since it knows all of the keys that this
object will ever use. Whereas a compiler for the actual
`unordered_map` type is expected to respect the hash function even if
the object is `constexpr`. A type defined by the language itself can
prevent users from doing things that would prevent someone from
noticing that the compiler has replaced the hash function.

Personally, I don't find this a reasonable thing to do even if a
compiler *could* do it. If you want perfect hashing for a compile-time
hash table, I would say that such a hash table should be a *different
type* from the type that doesn't provide perfect hashing. How a hash
table gets hashed ought to be a function of the object's type, not on
how that object was *declared*. The idea that sometimes a compiler
might in arbitrary cases just magically give types fundamentally
different properties, even built-in types, seems very dubious to me. I
can understand that for basic types like integers, floats, and
pointers. But anything more complex than that seems wrong-headed.

Yes, this imposes a burden on the user: the user must know about these
types and choose the one that best serves a particular need. But the
benefit of that is added flexibility: you have certain knowledge about
the nature of the object, not guesses/hopes about how compilers
*might* optimize it.