Re: [boost] Re: is_convertible corner case

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-24 19:01:10

"Peter Dimov" <pdimov_at_[hidden]> writes:

> From: "David Abrahams" <dave_at_[hidden]>
>> "Paul Mensonides" <pmenso57_at_[hidden]> writes:
>>
>> > I do, however, agree that we need more support from the language for
>> > generic programming and some type of standardized API into the
>> > compiler's type system.  And I definitely think that "undefined
>> > behavior" is unreasonable when the situation is easily diagnosable
>> > and not platform specific.
>>
>> I tend to agree on a "moral/aesthetic" level, but on a practical level
>> we have to tread carefully.  The question, "can we just have an
>> operator which produces a compile-time constant value saying whether
>> its operand is a valid expression?" has come up a few times in the
>> committee.  Each time, the implementors looked at their codebases and
>> said "oooh, that's really hard to do."  I think the short form of the
>> reason is that C++ compilers generally don't have the ability to
>> recover from errors reliably.  That may explain why your 2nd, 3rd,
>> 4th... diagnostic messages tend to be useless gibberish ;-)
>
> But how does this apply to is_convertible<X, int> when a private X::operator
> int()? Or are you discussing something else?

See below.

> I see no reason to make that undefined behavior. It's either "false", "true"
> (Comeau says true BTW), "unspecified", or "ill formed, no diagnostic
> required" - in order of preference.

"Ill formed with diagnostic required" was the possibility I was
thinking of.

You're right; undefined behavior is certainly not in the picture for
this case.

Never mind my brainless interjection, please ;-)

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution