title: How do I use comparator with is_transparent type?
body: <p>with C++14 we are allowed to compare elements of some associative containers (like std::set) with other types than the ones stored in a container. It's supposed to work when comparator has <code>is_transparent</code> denoted as a type (see e.g. <a href="http://en.cppreference.com/w/cpp/container/set/find">std::set::find</a>).</p>
  
  <p>Suppose I have a string wrapper which performs some checks on a string (if it's format is valid format and so on - not really important, but constructing it is heavy enough that I'd like to avoid it + it can throw exceptions) and it's stored in std::set to have a container of unique values. How should I write a comparator for it? Should it look like like the one below? Can I overload and use my <code>sw::operator&lt;()</code> to achieve the same?</p>
  
  <pre><code>class sw
  {
  public:
      explicit sw(const std::string&amp; s) : s_(s) { /* dragons be here */ }
      const std::string&amp; getString() const { return s_; }
  
      bool operator&lt;(const sw&amp; other) const { return s_ &lt; other.s_; }
  
  private:
      std::string s_;
  };
  
  struct Comparator
  {
      using is_transparent = std::true_type;
  
      bool operator()(const sw&amp; lhs, const std::string&amp; rhs) const { return lhs.getString() &lt; rhs; }
      bool operator()(const std::string&amp; lhs, const sw&amp; rhs) const { return lhs &lt; rhs.getString(); }
      bool operator()(const sw&amp; lhs, const sw&amp; rhs) const { return lhs &lt; rhs; }
  };
  
  int main() 
  {
      std::set&lt;sw, Comparator&gt; swSet{ sw{"A"}, sw{"B"}, sw{"C"} };
      std::cout &lt;&lt; std::boolalpha &lt;&lt; (swSet.find(std::string("A")) != swSet.end()) &lt;&lt; std::endl;
  }
  </code></pre>
  
  <p>I believe that above code should work as expected, but when I tested it with g++4.9 and clang++3.6, both yielded errors about missing conversion from <code>string</code> to <code>key_type</code> as if string overloads of <code>Comparator::operator()</code> were never taken into account. Am I missing something?</p>