
Thorsten Ottosen <nesotto@cs.aau.dk> writes:
David Abrahams <dave <at> boost-consulting.com> writes:
Thorsten Ottosen <nesotto <at> cs.aau.dk> writes:
then what about the following:
Returns:
x.first if x is an std::pair x if x is an array range_begin(x) if range_begin() can be found by ADL x.begin() otherwise
?
that would be an improvement. I think you need "otherwise," at the beginning of all lines of the 2nd column but the first.
like so
x.first if x is an std::pair, otherwise x if x is an array, otherwise range_begin(x) if range_begin() can be found by ADL, otherwise x.begin()
?
I personally think having one "otherwise" is ok. lot's of math do it like that.
I think I changed my mind. I agree with you.
Nitpicking,
range_begin(x) if range_begin() can be found by ADL
is not quite right. I think it's more like
range_begin(x) if range_begin(x) is well-formed in an arbitrary namespace.
but I'm not certain I have that right either.
hm...what about
if range_begin() can be found in namespaces associated with x.
Not quite right, because range_begin() denotes a function taking no arguments. You really should say range_begin(x) because it's an expression; it accounts for default arguments, function templates, derived->base conversions, etc.
OTOH, isn't that just ADL?
Yes, but the way you described it is just not correct; that's all. Oh, and I suppose an overload of range_begin in the global namespace would be found, provided it was declared before its point of use. That's why something like range_begin(x) if range_begin(x) is well-formed is more accurate.
Are you really detecting whether range_begin can be found via ADL?
No.
Then how are you arranging for the semantics to fall back to x.begin() when range_begin(x) can't be found? If you're not really doing that, you need to fix the docs.
I wrote code to do that trick, but I don't remember seeing it in the range lib.
Cool trick, though.
Yes; it's partly due to Doug Gregor. see boost/detail/is_incrementable.hpp
The suggested spec. says that the return-type depends on 4 cases, it doesn't state how these cases are implemented. I don't think they need to state that.
I don't understand what you're trying to say. Specific implementation details are not important, but the precise semantics of each case is important. -- Dave Abrahams Boost Consulting www.boost-consulting.com