----- Original Message ----- From: "Gennaro Prota" <[EMAIL PROTECTED]>
> >It's a similar problem to what happens > >if the To type has a private constructor taking the From type, my gut > >feeling is that both these cases have to be listed as "undefined behaviour". > > Ouch, no. You will never find me agreeing on this point. This seems > along the lines of "if I can't get it work, then it's undefined > behavior" which is a habit we should all get out of. As Paul > Mensonides wrote me (Paul, I hope you don't mind the quotation), UB is > reasonable e.g. when diagnosing the situation is impractical (for the > compiler), or when platform differences make it difficult to choose a > single specification without penalizing some of them, not when just we > don't know what to do. (I don't think that he means undefined behavior as far as the compiler is concerned, but I haven't been following this thread closely so I might be wrong.) At some point, especially with things of this nature, you have to say "this is valid input, and who knows what happens if you pass something else." This is especially the case when these type of "traits" templates are hacked up to make them work on various compilers--which makes it difficult to list invalid input. The most important issue is whether you can handle the most common and most useful cases. You can, of course, make a documented list of all things that are valid input and maybe as many things that you can think of that aren't for a strictly conforming compiler. You can also try to handle border case situations like this one if at all possible, but you can't always guarantee in the documentation that the border cases will always work with every compiler. 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. Paul Mensonides _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
