Re: [Boost-users] [Range] Proposal to add a new range adaptor (first_nd), or modify sliced

Subject: Re: [Boost-users] [Range] Proposal to add a new range adaptor (first_nd), or modify sliced
From: Neil Groves (neil_at_[hidden])
Date: 2012-08-30 22:36:52

Dear all,

On Monday, August 27, 2012, Nathan Ridge wrote:

>
> > Problem:
> > Get the first N element of a SinglePassRange. It is not possible with
> > sliced, because it requires RandamAccessRange.
>
> Note that this is possible with the 'taken' range adaptor [1] in the
> Boost.Range Extensions library [2] proposed by Akira Takahashi, which
> is on the review schedule [3], atlhough with no review date set yet.
>
>
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.

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!

> The equivalent of sliced(n, m) for SinglePassRanges is also possible
> by combining the 'taken' and 'dropped' [4] adaptors from that library:
>
> range | taken(n) | dropped(m)  // same elements as 'range | sliced(n, m)'
>
> Regards,
> Nate
>
>
I'd be interested in the communities preferences with regard to choosing
another review, or expedited merge.

Regards,
Neil Groves