Re: [boost] [range] [general] making member functions SFINAE-friendly

Subject: Re: [boost] [range] [general] making member functions SFINAE-friendly
From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2013-02-18 14:10:44

On 18 February 2013 18:56, Steven Watanabe wrote:
> AMDG
>
> On 02/18/2013 10:15 AM, Jonathan Wakely wrote:
>> On 18 February 2013 18:04, Dave Abrahams wrote:
>>>
>>>> However, if detecting whether "r.size()" is a valid expression
>>>> cannot be done reliably (for example, if we determine that for
>>>> iterator_range<I> where I is not random-access it is a valid
>>>> expression, but then that static-asserts on us), then we
>>>> can't use this approach.
>>>
>>> Then you can't use this approach (in general).
>>
>> Why?  What other range-like types provide an size() member that
>> appears to be callable but must not be called?
>>
>
> That's irrelevant.  The point is that the range
> concepts provide no such requirement.  It is unsafe
> to rely on any behavior which is not intentional and
> explicitly documented, /especially/ with generic code.

What range concepts?  The Boost ones? My template is not part of Boost
and does not claim to interoperate with Boost.Range or work with
models of its concepts.   My template works with standard containers
and arrays, someone tried to use it with iterator_range and it failed,
so I asked for a change to make iterator_range::size() more
user-friendly.  It seems that's unpopular, which is fine by me.
Nathan, feel free to close the ticket.