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

Subject: Re: [boost] [range] [general] making member functionsSFINAE-friendly
From: Nathan Ridge (zeratul976_at_[hidden])
Date: 2013-02-19 01:17:08

> 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?

Not if they are writing generic code, i.e. code where the 
iterator type is (or is dependent on) a template parameter).

> 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.

This was discussed upthread. To summarize, the standard library
makes the design choice of not providing certain operations
if they cannot be implemented with a certain asymptotic 
complexity (for example, subtraction of two iterators if it
cannot be implemented in constant time), and Boost is trying 
to be consistent with this design choice.

> 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.

Right, now the effect of calling size() on iterator_range<I>
where I is not random-access is a static assertion failure.

With the proposed change, the effect would be a compiler error
saying that the function doesn't exist at all. Is that worse
from a user's point of view? Perhaps, but not much.

Regards,
Nate