https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89477
--- Comment #4 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> --- libstdc++ passes all my test cases now except this one: ``` // https://godbolt.org/z/kvh9Ih #include <set> std::set<int> s; std::set t(s, std::allocator<long>()); ``` The issue is that we humans can logically deduce t's Allocator parameter as "the same as s's Allocator parameter", but due to an implementation detail, the compiler is also trying to deduce t's Allocator parameter as std::allocator<long>, and so it deduces conflicting types and fails deduction. This test case could be made to work if you changed https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_set.h#L124 from typedef _Alloc allocator_type; to typedef typename __identity<_Alloc>::type allocator_type; or whatever libstdc++'s equivalent of __identity is. MSVC's `set` already effectively does this, by inheriting its `allocator_type` typedef from a base class. I don't know whether the paper standard has a definite interpretation one way or the other; it might be open to interpretation, or it might even say that MSVC is wrong in this case. (Logically, I think MSVC *should* be right.) Perhaps a new bugzilla issue should be opened for this one.
