Re: [boost] [Range] Confusing result of iterator_range::size()

Subject: Re: [boost] [Range] Confusing result of iterator_range::size()
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-11-03 05:13:19

On Thu, Nov 3, 2011 at 1:54 AM, Thorsten Ottosen <
thorsten.ottosen_at_[hidden]> wrote:

> Den 03-11-2011 09:12, Sergey Voropaev skrev:
>
>> Jeffrey Lee Hellrung, Jr.<jeffrey.hellrung<at>  gmail.com>  writes:
>>
>>
>>> This came up just recently, e.g.,
>>>
>>> http://comments.gmane.org/**gmane.comp.lib.boost.devel/**224758
>

>>>
>> Sorry, I miss it. Good discussion. And now we have my example with
>> compilation
>> error.
>>
>>>
>>> I think the end result was an agreement that
>>>
>>> typedef typename boost::make_unsigned<  difference_type>::type size_type
>>>
>>> would be a valid definition of size_type, so the only argument against
>>> making the change that I can see is breaking existing code (probably
>>> unlikely...?) and...inertia.
>>>
>>
> Well, its /not/ unlikely that it will break code.
>

Well, okay, sure, *some* code is going to break.  Do you have actual code
(i.e., not contrived examples) that you predict would fail?

Given that this has come up twice in the last month, I think it's worth
discussing the fallout from such a change.  If one were to redesign
boost::iterator_range all over again, is there an argument *against* making
size() return an unsigned type?

- Jeff