Re: [boost] [range] [general] making member functionsSFINAE-friendly

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 <jwakely.boost-AT-kayari.org>
> 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.
> <http://grokbase.com/t/python/python-list/02c225syvb/source-code-size-metric-python-and-modern-c#20021207htb5htssa6yj355yhcjbz4wm7y>
>
> There's no "range-like."  There's a family of Range concepts:
> http://www.boost.org/doc/libs/1_53_0/libs/range/doc/html/range/concepts.html
> http://www.boost.org/community/generic_programming.html#concept
>
> 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 
things
of interest:

a) Documentation says that it fullfills the ForwardIteratorRange concept - 
OK
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:

template<ForwardIteratorRange>
class forward_iterator_range {
    ...
};

...

template<RandomIteratorRange>
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