I like this 👍 . Since you have a branch in the logic for more than 16 keys of the same size I would say we need some specs to cover that. Just to be sure it does not break in the future.

Let's see if some else agree with this before.

I'm not sure about this, a named tuple is not to be used as a hash. They represent named arguments, to a method, and methods usually don't have many arguments. I'd rather have a short and simple implementation, even if a bit slower, than a complex, macro heavy one.

I'd need to find a real use case where big named tuples are used, and indexed with an arbitrary key.

If you have such a big datastructure, I don't see a point in using a NamedTuple as well.
A Hash has about the same lookup speed anyway, in this example it's even faster. But I had to cut down the number of entries in the NamedTuple since the compiler maxes at 300.

check every key   2.99  (334.04ms) (±24.93%) 341.02× slower
    trie lookup  34.87  ( 28.68ms) (± 9.12%)  29.28× slower
           hash   1.02k (979.55µs) (±11.60%)        fastest

https://gist.github.com/straight-shoota/cb903575c6dd86d1c6c86c372d842666

NamedTuple looks like returning value pattern, and eats less memory afair.

No more.

Closing because too complex, and NamedTuple shouldn't normally be used.