From: David Abrahams (dave_at_[hidden])
Date: 2005-09-15 09:35:30
Thorsten Ottosen <nesotto_at_[hidden]> 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
> 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.
>> 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
>> but I'm not certain I have that right either.
> hm...what about
> if range_begin() can be found in namespaces associated with
Not quite right, because range_begin() denotes a function taking no
arguments. You really should say
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?
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
> 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
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk