title: Infinite recursive template instantiation expected?
body: <p>I am trying to understand why a piece of template metaprogramming is <strong>not</strong> generating an infinite recursion. I tried to reduce the test case as much as possible, but there's still a bit of setup involved, so bear with me :)</p>
  
  <p>The setup is the following. I have a generic function <code>foo(T)</code> which delegates the implementation to a generic functor called <code>foo_impl</code> via its call operator, like this:</p>
  
  <pre><code>template &lt;typename T, typename = void&gt;
  struct foo_impl {};
  
  template &lt;typename T&gt;
  inline auto foo(T x) -&gt; decltype(foo_impl&lt;T&gt;{}(x))
  {
      return foo_impl&lt;T&gt;{}(x);
  }
  </code></pre>
  
  <p><code>foo()</code> uses decltype trailing return type for SFINAE purposes. The default implementation of <code>foo_impl</code> does not define any call operator. Next, I have a type-trait that detects whether <code>foo()</code> can be called with an argument of type <code>T</code>:</p>
  
  <pre><code>template &lt;typename T&gt;
  struct has_foo
  {
      struct yes {};
      struct no {};
      template &lt;typename T1&gt;
      static auto test(T1 x) -&gt; decltype(foo(x),void(),yes{});
      static no test(...);
      static const bool value = std::is_same&lt;yes,decltype(test(std::declval&lt;T&gt;()))&gt;::value;
  };
  </code></pre>
  
  <p>This is just the classic implementation of a type trait via expression SFINAE:
  <code>has_foo&lt;T&gt;::value</code> will be true if a valid <code>foo_impl</code> specialisation exists for <code>T</code>, false otherwise. Finally, I have two specialisations of the the implementation functor for integral types and for floating-point types:</p>
  
  <pre><code>template &lt;typename T&gt;
  struct foo_impl&lt;T,typename std::enable_if&lt;std::is_integral&lt;T&gt;::value&gt;::type&gt;
  {
      void operator()(T) {}
  };
  
  template &lt;typename T&gt;
  struct foo_impl&lt;T,typename std::enable_if&lt;has_foo&lt;unsigned&gt;::value &amp;&amp; std::is_floating_point&lt;T&gt;::value&gt;::type&gt;
  {
      void operator()(T) {}
  };
  </code></pre>
  
  <p>In the last <code>foo_impl</code> specialisation, the one for floating-point types, I have added the extra condition that <code>foo()</code> must be available for the type <code>unsigned</code> (<code>has_foo&lt;unsigned&gt;::value</code>).</p>
  
  <p>What I don't understand is why the compilers (GCC &amp; clang both) accept the following code:</p>
  
  <pre><code>int main()
  {
      foo(1.23);
  }
  </code></pre>
  
  <p>In my understanding, when <code>foo(1.23)</code> is called the following should happen:</p>
  
  <ol>
  <li>the specialisation of <code>foo_impl</code> for integral types is discarded because <code>1.23</code> is not integral, so only the second specialisation of <code>foo_impl</code> is considered;</li>
  <li>the enabling condition for the second specialisation of <code>foo_impl</code> contains <code>has_foo&lt;unsigned&gt;::value</code>, that is, the compiler needs to check if <code>foo()</code> can be called on type <code>unsigned</code>;</li>
  <li>in order to check if <code>foo()</code> can be called on type <code>unsigned</code>, the compiler needs again to select a specialisation of <code>foo_impl</code> among the two available;</li>
  <li>at this point, in the enabling condition for the second specialisation of <code>foo_impl</code> the compiler encounters again the condition <code>has_foo&lt;unsigned&gt;::value</code>.</li>
  <li>GOTO 3.</li>
  </ol>
  
  <p>However, it seems like the code is happily accepted both by GCC 5.4 and Clang 3.8. See here: <a href="http://ideone.com/XClvYT">http://ideone.com/XClvYT</a></p>
  
  <p>I would like to understand what is going on here. Am I misunderstanding something and the recursion is blocked by some other effect? Or maybe am I triggering some sort of undefined/implementation defined behaviour?</p>