https://svn.boost.org/trac10/ticket/6913 <p> It would be nice to avoid specialization of <code>result_of</code>, when we use decltype-based <code>result_of</code>. (As for <code>tr1_result_of</code>, it should be specialized even when decltype-based <code>result_of</code> is enabled.) </p> <p> A quick grep said the following file specializes <code>result_of</code>. </p> <ul><li>proto/generate.hpp </li></ul> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/6913 Trac 1.4.3 Eric Niebler Mon, 21 May 2012 06:51:31 GMT https://svn.boost.org/trac10/ticket/6913#comment:1 https://svn.boost.org/trac10/ticket/6913#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> I know I asked you to file this bug. But when I went to make the change, I found I had left myself the following comment in the code: </p> <pre class="wiki">// Specializations of boost::result_of and boost::tr1_result_of to eliminate // some unnecessary template instantiations </pre><p> The comment is correct. Although strictly unnecessary in a decltype world, the <code>boost::result_of</code> specializations do bring down the number of template instantiations, which speeds up compile times. The specializations aren't actually hurting anything, so I'm leaving them in. (Note also the specializations are for unary function invocations, so they were never there to address the nullary limitation of <code>tr1::result_of</code>. They are strictly to bring down TMP overhead.) </p> <p> If you find a situation where the specializations are causing a problem, feel free to reopen this bug. Thanks. </p> Ticket