On Thu, Nov 3, 2011 at 1:54 AM, Thorsten Ottosen < thorsten.ottosen@dezide.com> 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.,
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