[lmi] How does T differ from std::set<T>::key_type?

[Greg Chicares]

Consider the patch below [0], which causes the 'contains_test' unit test
to fail with gcc-3.4.5, como-4.3.3, and the antique borland-5.5.1, whereas
without this patch all these tests succeed with all those compilers.

Why? Isn't 'typename std::set<T>::key_type' the same as just plain 'T'?
The argument type is, say, char const[8], whereas T is deduced to be
std::string, but why does the conversion to string work with HEAD but
fail with the patch?

BTW, I would be glad to learn whether this unit test (the version in HEAD)
fails with any other compiler you may have available.

---------
[0] "the patch below"

Index: contains.hpp
===================================================================
--- contains.hpp        (revision 4948)
+++ contains.hpp        (working copy)
@@ -30,7 +30,7 @@

 #include <algorithm> // std::find()

-#if defined __BORLANDC__ || defined __COMO_VERSION__ && __COMO_VERSION__ <= 
4303
+#if true || defined __BORLANDC__ || defined __COMO_VERSION__ && 
__COMO_VERSION__ <= 4303
 #   define LMI_NO_SFINAE
 #   include <deque>
 #   include <list>
@@ -152,13 +152,13 @@
 // Associative containers.

 template<typename K, typename T>
-bool contains(std::map<K,T> const& t, typename std::map<K,T>::key_type const& 
element)
+bool contains(std::map<K,T> const& t, K const& element)
 {
     return t.end() != t.find(element);
 }

 template<typename T>
-bool contains(std::set<T> const& t, typename std::set<T>::key_type const& 
element)
+bool contains(std::set<T> const& t, T const& element)
 {
     return t.end() != t.find(element);
 }