Re: [boost] Re: Re: is_convertible: rationale and wording
Mike Conley <[EMAIL PROTECTED]> writes: > "John Maddock" <[EMAIL PROTECTED]> wrote in > news:[EMAIL PROTECTED]: > >> The problem is that the question "is A convertible to B" has four >> answers: yes, no, ill-formed, and ambiguous :-( >> >> John. > > Obviously, I think there should be only two :) That is, it would be nice > to have a test that tells me the whether or not an assignment would or > would not succeed. If I want to assign the result of an expression to a > variable (or use it as a return value, etc), I don't particularly care WHY > an assignment would fail. I just want to know whether it would or not. 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. > Perhaps it would be useful to have a set of tests that can tell you whether > a conversion would fail for a specific reason, eg, conversion_is_ambiguous > . Which begs the same question as the one I'm harping on above. > But the real problem, as I see it, is that is_convertible can fail to > compile for certain choices of X and Y. That defeats the purpose of the > test -- why would I ask if I can convert an X to a Y if I must already know > the answer to do so safely? That's a whole different (and soluble, in the core) matter. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_convertible: rationale and wording
"John Maddock" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > The problem is that the question "is A convertible to B" has four > answers: yes, no, ill-formed, and ambiguous :-( > > John. Obviously, I think there should be only two :) That is, it would be nice to have a test that tells me the whether or not an assignment would or would not succeed. If I want to assign the result of an expression to a variable (or use it as a return value, etc), I don't particularly care WHY an assignment would fail. I just want to know whether it would or not. Perhaps it would be useful to have a set of tests that can tell you whether a conversion would fail for a specific reason, eg, conversion_is_ambiguous . But the real problem, as I see it, is that is_convertible can fail to compile for certain choices of X and Y. That defeats the purpose of the test -- why would I ask if I can convert an X to a Y if I must already know the answer to do so safely? -- Mike Conley ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_convertible: rationale and wording
Mike Conley <[EMAIL PROTECTED]> writes:
> David Abrahams <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
>> This one is sticky.
>>
>> class Y : X { true_type f() { return is_convertible::type();
>> } }; false_type x = is_convertible::type();
>>
>
> I'm not sure I see the problem here. If is_convertible is a built in
> compile time operator, the results should depend upon context. This should
> work as expected. Really, it's no more interesting than:
>
> char c[23];
> cout << sizeof(c);
> {
>char c[22];
>cout << sizeof(c);
> }
>
> printing 2322.
What about the ODR?
Further, suppose I write a metafunction:
template
struct is_const_and_int_convertible
: and_<
is_const
, is_convertible
>
{};
Does this one depend on context also?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_convertible: rationale and wording
David Abrahams <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> This one is sticky.
>
> class Y : X { true_type f() { return is_convertible::type();
> } }; false_type x = is_convertible::type();
>
I'm not sure I see the problem here. If is_convertible is a built in
compile time operator, the results should depend upon context. This should
work as expected. Really, it's no more interesting than:
char c[23];
cout << sizeof(c);
{
char c[22];
cout << sizeof(c);
}
printing 2322.
--
Mike Conley
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
