[C++-sig] Re: Adding __len__ to range objects

[Raoul Gough]

David Abrahams <dave at boost-consulting.com> writes:

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>> David Abrahams <dave at boost-consulting.com> writes:
[snip]
>>> I think you're barking up the wrong tree.  Maybe we ought to simply
>>> change our tune and say that range() produces an iterable-returning
>>> function rather than an iterator-returning function.  If we did that
>>> we could always generate __len__, and for that matter we could also
>>> generate __getitem__/__setitem__ for random-access ranges.
>>
>> Sounds good to me. I think Andreas was also suggesting something in
>> this direction. I was almost going to suggest adding a _new_ C++
>> sequence wrapper (e.g. called view or sequence_view) that provides the
>> extra stuff as well as __iter__ support via the existing range
>> code. The only real benefit would be that the client code could then
>> choose whether to include the more sophisticated support. 
>
> Too many options; not enough benefit.

Yep.

>
>> Maybe you could achieve this via an optional iterator_category
>> anyway (as you pointed out, __len__ is probably a bad idea for
>> input_iterators).
>
> Don't know what this means.

Just thinking that a parameter somewhere that defaults to
iterator_traits<Iterator>::iterator_category would allow the user to
choose a weaker iterator category if they didn't want the extra
stuff. Probably not worth the effort, actually.

>
> Anyway, I'm not going to implement this one myself.  Patches
> (including docs and tests) will be gratefully considered.

I should get some time to work something out this week. Will post the
results when ready.

-- 
Raoul Gough
"Let there be one measure for wine throughout our kingdom, and one
measure for ale, and one measure for corn" - Magna Carta