Fix problems with heterogeneous insert input types

[sleeepyjack]

This PR fixes some of the problems with heterogeneous insert for static_map.
The input type to any of the insert(_*) operators is now cuco::pair<ProbeKey, mapped_type>.

Also updates docs for both map and set regarding type requirements of ProbeKey.

Also adds a small convenient abstraction aka attempt_insert_stable.

[PointKernel]

native_value is used only once. Either it's not needed or it should be applied in other places as well.

[sleeepyjack]

I'd say yes, but I think I will need that function for insert_or_apply soon. We can either introduce the function in this PR or the insert_or_apply PR.

[sleeepyjack]

I fucked up the merge…investigating

[PointKernel]

One question: when to use heterogeneous_value and when to use native_value?

[sleeepyjack]

One question: when to use heterogeneous_value and when to use native_value?

heterogeneous_value is what you use whenever you need to call the custom hasher or key equals functor. native_value is what's stored in the container. The only difference is that heterogeneous_value holds a potentially custom key type while native_value always holds the native key type of the container.

The workflow is as follows: Take the user-provided pair-like input type and convert it to heterogeneous_value. This is the value type that is used internally and works with the custom hasher/predicate. Once you want to store the value, you convert it into native_value. So it's Value->heterogeneous_value->native_value.

[PointKernel]

One question: when to use heterogeneous_value and when to use native_value?

heterogeneous_value is what you use whenever you need to call the custom hasher or key equals functor. native_value is what's stored in the container. The only difference is that heterogeneous_value holds a potentially custom key type while native_value always holds the native key type of the container.

The workflow is as follows: Take the user-provided pair-like input type and convert it to heterogeneous_value. This is the value type that is used internally and works with the custom hasher/predicate. Once you want to store the value, you convert it into native_value. So it's Value->heterogeneous_value->native_value.

When dealing with hasher/comparator, can we use extract_key?

[sleeepyjack]

When dealing with hasher/comparator, can we use extract_key?

You mean using the user-provided pair-like type instead of the heterogeneous intermediate type internally and use extract_… on-demand?
The problem with that is that we don't even know on how to extract the members if it's any arbitrary type. cuda::std::get? thrust::get? .first/.second? This is just not manageable. Thus, we convert it to a cuco::pair first using heterogeneous_value, so we know how to access the members in a uniform fashion. From there, we can access the members directly without using any extract_… functions.

[PointKernel]

When dealing with hasher/comparator, can we use extract_key?

You mean using the user-provided pair-like type instead of the heterogeneous intermediate type internally and use extract_… on-demand? The problem with that is that we don't even know on how to extract the members if it's any arbitrary type. cuda::std::get? thrust::get? .first/.second? This is just not manageable. Thus, we convert it to a cuco::pair first using heterogeneous_value, so we know how to access the members in a uniform fashion. From there, we can access the members directly without using any extract_… functions.

So we could remove extract_key and just use val.first instead all over the place?

[sleeepyjack]

So we could remove extract_key and just use val.first instead all over the place?

extract_key also handles the distinction between static_set and static_map, i.e., returning val or val.first.

[PointKernel]

LGTM