suggested resiliency/ease-of-use

[Dave Abrahams]

If I define a range type X and define only

X::iterator range_begin(X const&);

assuming that it should be picked up for const or non-const X, generic code will break when passed a non-const X when it tries to do boost::begin(x) and that expression reaches inside X looking for a begin() member.

It's possible to make the library resilient against this issue as shown by the enclosed example

[anonymous]

I could "fix" the code for range2 by adding one typedef:

struct range2 {

range2() {}

typedef char* iterator; typedef iterator const_iterator; this one added char* begin() const { return 0; }

};

Is that good enough, or do you still think it is a big problem that two versions of range_begin() needs to be defined?

-Thorsten

[Dave Abrahams]

The problem is what happens with range1 with today's library. I put range2 in there just to prove that my solution doesn't break the other cases.

[nesotto@…]

Ok, I wondering if we could make it a bit simpler by only disabling begin( T& ) if the two iterator types are the same? Or do you want it to work if only one of the iterator types is defined?

-Thorsten

[Dave Abrahams]

Oh, well, I suppose it's preferable to work with only one of the iterator types defined as well. On the other hand, I realize this whole thing is really only an issue for a person who is adapting an existing type to the Range concept, since the rest of us can use member functions and nested typedefs, which is sufficiently economical. You might consider whether it is important enough to do anything about.