Boost logo

Boost :

Subject: Re: [boost] [range] [general] making member functionsSFINAE-friendly
From: Robert Ramey (ramey_at_[hidden])
Date: 2013-02-18 19:06:03

Dave Abrahams wrote:
> on Mon Feb 18 2013, Jonathan Wakely <>
> wrote:
>> On 18 February 2013 18:30, Andrey Semashev wrote:
>>> On Monday 18 February 2013 15:05:11 Jonathan Wakely wrote:
>>>> On 18 February 2013 14:33, Andrey Semashev wrote:
>>>>> Yes, I'm aware of type traits. It's one thing to do
>>>>> tests/transforms on types and another to test for methods
>>>>> presence and behavior. It's doable but it is much more fragile
>>>>> and dangerous, as you have already discovered with iterator_range.
>>>> It's only fragile because iterator_range defines a member which
>>>> can't be used.
>>> No, it broke with iterator_range. It can break with other types
>>> with different signatures and/or semantics of size().
>> Given that I'm already requiring the type can be used with
>> std::begin() and std::end(), i.e. is range-like, I'm happy to not
>> support types that have a non-range-like size(). If your type quacks
>> like a duck but swims like a fish it doesn't meet my requirements for
>> a duck.
> This sounds like the language commonly used in the Python community
> about (their version of) concepts.
> <>
> There's no "range-like." There's a family of Range concepts:
> Maybe I'm off base here, but reading the above makes it hard for me to
> hear the rest of what you wrote.

FWIW - we had a thread a couple of months ago regarding Boost Range
concepts, how they were defined and how they were implemented and
what they should mean for users of Boost Range. I was dissatisfied with
all three of these aspects of Boost Range but couldn't convince anyone
else of my point of view.

Looking that the documentation/synopsis of iterator_range<T> I see a few
of interest:

a) Documentation says that it fullfills the ForwardIteratorRange concept -
b) But then it includes the size() function - so doesn't that mean that it
full fills
the concept for RandomAccessRange concept? very confusing.
c) shouldn't there be:

class forward_iterator_range {


class random_access_iterator_range : public {
    size_type size() const;

Boost Range concept doesn't specify size() for a ForwardIteratorRange. But
I think this is another mistake since size() could be implemented (in a
different way)
for iterators fullfilling this concept.

Wouldn't restructuring interator_range along the lines of the above resolve
all the confusion here?

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at