[boost] Re: Re: Re: is_convertible: rationale and wording

From: Mike Conley (conley.141_at_[hidden])
Date: 2003-04-27 10:44:55

David Abrahams <dave_at_[hidden]> wrote in
news:u3ck4yp5d.fsf_at_[hidden]: 

> 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