[Bug]: `flat_hash_map` incorrectly reports copyability

[asoffer]

Describe the issue

std::is_copy_constructible_v<absl::flat_hash_map<K, V>> is true even when std::is_copy_constructible_v<V> is false.

Steps to reproduce the problem

https://godbolt.org/z/M7M9bqG5c

What version of Abseil are you using?

20250121.0

What operating system and version are you using?

Tested on Ubuntu, MacOS.

What compiler and version are you using?

Tested on both clang and gcc

What build system are you using?

bazel 8.1.1

Additional context

Being sfinae friendly here is pretty important because standard library containers expect it. In my case, I had a std::vector<std::pair<A, B>> where B was a wrapper around an absl::flat_hash_map<std::string, MoveOnly>. Calls to emplace_back<A&&, B&&>, which was very confusing.

The workaround is to explicitly declare the copy/move constructors explicitly for my wrapper as delete/default respectively so the trait doesn't dig into the implementation.

FWIW, std::unordered_map seems to have the same problem in both libc++ and libstdc++. I don't know of anything in the standard that requires this behavior. Also because it's detectable, a change can in theory constitute an ABI break, so that's fun. I know Abseil doesn't care, but there's an interesting question about divergence from standard behavior here.

[derekmauro]

https://quuxplusone.github.io/blog/2020/02/05/vector-is-copyable-except-when-its-not/

I'll have to figure out how we should handle this (if at all), but it is not high priority at the moment.

[asoffer]

Thanks for the reference. absl::flat_hash_map already doesn't support incomplete types, so the tradeoff is less important here than for the standard.

Anyway, I totally understand why this is low-priority. Thanks for following up.