Boost logo

Boost :

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 <> wrote:

> On 18 February 2013 18:56, Steven Watanabe wrote:
>> 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

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