Dear all,<br><br>On Monday, August 27, 2012, Nathan Ridge  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; Problem:<br>
&gt; Get the first N element of a SinglePassRange. It is not possible with<br>
&gt; sliced, because it requires RandamAccessRange.<br>
<br>
Note that this is possible with the &#39;taken&#39; range adaptor [1] in the<br>
Boost.Range Extensions library [2] proposed by Akira Takahashi, which<br>
is on the review schedule [3], atlhough with no review date set yet.<br>
<br></blockquote><div><br></div><div>I wonder if this is the best plan. In my time following Boost we have already had two reviews for Boost.Range. These additions appear to be incremental and cohesive with the existing design idioms.</div>
<div><br></div><div>Would it be more appropriate to have me spend some time bringing the functionality into the trunk of Boost.Range? I would imagine we could deliver the desired result more quickly for Boost.Range and reduced the queue size to the benefit of other components? I promise to be less rubbish than I have been the past few months looking after my Trac tickets!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The equivalent of sliced(n, m) for SinglePassRanges is also possible<br>
by combining the &#39;taken&#39; and &#39;dropped&#39; [4] adaptors from that library:<br>
<br>
range | taken(n) | dropped(m)  // same elements as &#39;range | sliced(n, m)&#39;<br>
<br>
Regards,<br>
Nate<br><br></blockquote><div><br></div><div>I&#39;d be interested in the communities preferences with regard to choosing another review, or expedited merge.</div><div><br></div><div>Regards,</div><div>Neil Groves </div>