title: Conversion is ambiguous in Visual Studio 2015, but not with clang
body: <p>The following code, a simplified version of code found in the googlemock project, fails to compile in Visual Studio 2015 Update 1, but it compiles on clang [Apple LLVM version 7.0.0 (clang-700.1.76)].</p>
  
  <pre><code>struct ConvertibleFromAny
  {
      ConvertibleFromAny(int a_value);
  
      template &lt;typename T&gt;
      ConvertibleFromAny(const T&amp; a_value);
  };
  
  template &lt;typename T&gt;
  struct Matcher
  {
      Matcher(T value);
  };
  
  template &lt;typename Rhs&gt;
  struct EqMatcher
  {
      explicit EqMatcher(const Rhs&amp; rhs);
  
      template &lt;typename Lhs&gt;
      operator Matcher&lt;Lhs&gt;() const;
  };
  
  int main()
  {
      EqMatcher&lt;ConvertibleFromAny&gt; em(1);
      Matcher&lt;ConvertibleFromAny&gt; m = em;
  
      return 0;
  }
  </code></pre>
  
  <p>The error occurs at the <del>assignment</del> statement</p>
  
  <pre><code>Matcher&lt;ConvertibleFromAny&gt; m = em;
  </code></pre>
  
  <p>and the error message is</p>
  
  <pre><code>error C2440: 'initializing': cannot convert from 'EqMatcher&lt;ConvertibleFromAny&gt;' to 'Matcher&lt;ConvertibleFromAny&gt;'
  note: No constructor could take the source type, or constructor overload resolution was ambiguous
  </code></pre>
  
  <p>I can naively see an ambiguity between a member call to</p>
  
  <pre><code>EqMatcher&lt;ConvertibleFromAny&gt;::operator Matcher&lt;ConvertibleFromAny&gt;()
  </code></pre>
  
  <p>and an initialization conceptually similar to</p>
  
  <pre><code>Matcher&lt;ConvertibleFromAny&gt; m(ConvertibleFromAny&lt;EqMatcher&lt;ConvertibleFromAny&gt;&gt;(em))
  </code></pre>
  
  <p>My guess is that clang rules out the second option.</p>
  
  <p>EDIT: Inspired by T.C.'s comment I tested the following:</p>
  
  <pre><code>struct A
  {
  };
  
  struct X
  {
      X(const A&amp;);
  };
  
  struct B
  {
      B(const X&amp;);
  };
  
  int main()
  {
      A a;
  
      B b = a;
  }
  </code></pre>
  
  <p>It compiles with VS 2015, but not with clang. I have not been able to find any references that documents that the Visual C++ implementation intentionally deviates from the standard in this regard.</p>
  
  <p>Is this a well-known problem?</p>