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

Subject: Re: [boost] [range] [general] making member functions SFINAE-friendly
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-02-18 17:41:16

on Mon Feb 18 2013, Jonathan Wakely <jwakely.boost-AT-kayari.org> wrote:

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

I am not sure it's unpopular.  I think there's just some concern about
whether it achieves what we ultimately want.  Maybe there's a more
generally-useful way to get the same benefits.

-- 
Dave Abrahams