Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-09-18 10:02:17


David Abrahams <dave <at> boost-consulting.com> writes:

>
> Thorsten Ottosen <nesotto <at> cs.aau.dk> writes:

> >> How about
> >>
> >> range_begin(x) if it would invoke a function found by argument
> >> dependent lookup.
> >>
> >> ?
> >

> > but it also appears fairly cryptic to me.
>
> What's cryptic about it?

the compiler doesn't care about invoking something...that happens at runtime
IMO.

> Here are a few other options that are
> similarly precise:
>
> range_begin(x) if it would result in range_begin being found by
> argument dependent lookup.
>
> range_begin(x) if there is a matching range_begin in a namespace
> associated with the type of x.
>
> > If the only problem was
> > that ADL applies to function overloads (or names in general), then
> > why not just strip the "(x)":
> >
> > range_begin(x) if range_begin can be found by ADL
> >
> > ? Wouldn't this account for all names (not just function overloads)?
>
> It lacks precision; it doesn't force that range_begin that's found to
> be in a namespace associated with the single argument x.

hm...AFAICT, only the last of your three versions mentions the namespace
associated with x.

> Just because
> there's a range_begin that *can* be found via ADL doesn't mean it will
> be found in that expression.

ok, I think I'm getting it...for example, the a base class version
of begin can be found, but derived to base classs reference will not happen
and so t.begin() is called instead.

I like this version best:

range_begin(x) if it would result in range_begin being found by
               ADL

> This is nitpicky, but I think the
> language is slightly clearer.

right. somehow we still don't say when it wouldn't be found. The question is,
maybe, is the overload actually found, but then later, during overload
resolution,
discarded as a best match?

In that light I think

    range_begin(x) if there is an exactly matching range_begin in a namespace
    associated with x.

is better. we then need to state that "exactly matching" means without no
implicit conversions required.

-Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk