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

Subject: Re: [boost] [range] [general] making member functions SFINAE-friendly
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-02-18 17:28:48

On Mon, Feb 18, 2013 at 11:10 AM, Jonathan Wakely
<jwakely.boost_at_[hidden]>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.
> Nathan, feel free to close the ticket.
>

IMHO, Jon's making a reasonable QOI request, it's just the costs to
implement it don't appear (in the view of the community) to outweigh the
benefits. Philosophically, all things being equal, I'm on board with
iterator_range only defining those member functions it actually supports;
sadly, the language doesn't make this trivial :(

- Jeff