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-19 00:20:07

Nathan Ridge wrote:
>> c) shouldn't there be:
>>
>> template<ForwardIteratorRange>
>> class forward_iterator_range {
>> ...
>> };
>>
>> ...
>>
>> template<RandomIteratorRange>
>> class random_access_iterator_range : public {
>> size_type size() const;
>> };
>>
>> ...
>>
>> Wouldn't restructuring interator_range along the lines of the above
>> resolve all the confusion here?
>>
>> Robert Ramey
>
> It would solve Jonathan's problem, sure.
>
> But it would also hurt people who are trying to use
> iterator_range to package a pair of arbitrary iterators
> in generic code (which IMO is one of iterator_range's
> major use cases), because they would now have to use
> different classes for different types of iterators.

But doesn't the caller know the concept which his iterator
pair models?

Hmmm - different subject - when I think about it, it would
seem to be that the ForwardIteratorRange concept should in
fact support size() since this is easily implementable (albeit inefficiently 
so).
I believe that this would also address the original question.

But what really bugs me about the proposal is that it
introduces hidden non-obvious behavior. I might invoke
size() where it seems "obvious" that it should work and
then something else happens because of SFINAE.
The current situation where one does something "obvious"
but wrong traps with a  fault is far superior.  I would say that
boost in general has too much code which is smarter than the programmer
calling it.  This makes for surprising behavior which is
hard to track down.

Robert Ramey

> Regards,
> Nate
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost