David Abrahams <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> The problem I was trying to point out with is_const_or_int_convertible
> was that if you want it to "just work" you really want some way of
> "grabbing context" at the interface to any metafunction that might
> need it, and passing it all the way down into is_convertible, so that
> it gets evaluated in the context of the "outer invocation" whatever
> that is.
Right. But you only have that problem if you want to wrap
is_convertible inside a metafunction. Better to just use and_ directly.
The way to capture the context is to make it part of the type of your
metafunction:
template <class T, bool ic>
struct my_metafunction { /* ... */ };
// is_convertible operator applied in current context & passed to
// my_metafunction.
my_metafunction<int, is_convertible<int, double> >
This also neatly solves any ODR problems. I'll admit it isn't as
usable, though.
>> But the real problem, as I see it, is that is_convertible<X,Y> can
>> fail to compile for certain choices of X and Y.
> That's a whole different (and soluble, in the core) matter.
What sorts of changes would be (or are being) considered?
--
Mike Conley
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
