Boost logo

Boost :

Subject: [boost] [range] [general] making member functions SFINAE-friendly
From: Nathan Ridge (zeratul976_at_[hidden])
Date: 2013-02-18 00:30:10


I recently came across a request to make iterator_range<I>::size()
SFINAE-friendly [1].

The respect in which it is not currently SFINAE-friendly is that
it is only applicable to instantiations where I is a random-access
iterator, but it is defined for all instantiations, and fails with
a static assertion if I is not random-access. This makes it
impossible to use SFINAE techniques to detect whether "r.size()"
is valid where r is some iterator_range.

The suggested workaround is to give iterator_range a base class,
specialize this base class for random-access iterators, and only
define size() in this specialization.

I think this deficiency and workaround can be generalized to any
template class 'C<T>' with a member function 'foo' that is only
applicable for a subset of valid template arguments for 'T'. I am
curious what the Boost community thinks about applying this
workaround (factoring out the member function into a base class)
as a general rule in such situations? Is making the member
function SFINAE-friendly worth the decrease in readability? Are
there other disadvantages to this workaround?

Are there alternative ways of making such a function SFINAE-
friendly that don't require introducing a base class?

Finally, if the consensus is that such a workaround is not
justified in general, is there any reason it should be justified
specifically for iterator_range<I>::size()?



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