Boost C++ Libraries: Ticket #1519: lvalue-ness resurrection in transform_iterator https://svn.boost.org/trac10/ticket/1519 <p> The patch for a function returning lvalue. See: <a class="ext-link" href="http://lists.boost.org/Archives/boost/2007/12/131439.php"><span class="icon">​</span>http://lists.boost.org/Archives/boost/2007/12/131439.php</a> </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/1519 Trac 1.4.3 Shunsuke Sogame <pstade.mb@…> Tue, 11 Dec 2007 01:43:30 GMT attachment set https://svn.boost.org/trac10/ticket/1519 https://svn.boost.org/trac10/ticket/1519 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">lvalue_function.patch</span> </li> </ul> <p> extracts pure traversal tag </p> Ticket Dave Abrahams Sun, 06 Jun 2010 15:39:25 GMT status changed; resolution set https://svn.boost.org/trac10/ticket/1519#comment:1 https://svn.boost.org/trac10/ticket/1519#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">invalid</span> </li> </ul> <p> If I understand correctly what your patch is doing, you are effectively determining whether the resulting <code>transform_iterator&lt;...&gt;</code> satisfies the access requirements of ForwardIterator (and thus, RandomAccessIterator) by looking at the lvalueness of the transformed result_type. Unfortunately, that's not a valid way to make the determination, because the resulting iterator doesn't suddenly become multipass just because of a change in the reference type. In fact, most of the standard's InputIterators return references from their <code>operator*</code>. </p> Ticket