> A string literal (narrow or wide) is an lvalue. Yes, you're right, however it's still a non-issue: array to pointer conversions are allowed (int[2] to const int* for example), so this will do the right thing anyway. The string literal to pointer conversion is just a special case of a more general conversion, or am I still missing something?
> >Now that one is just plain nasty :-( > > Sorry. That wasn't my intention. It's just that I take the issue > seriously (as you certainly do as well). I know, it is unpleasant to > discover complications in something that seemed so simple and elegant, > but we must do it. Better discovering problems now than late, don't > you think? Absolutely, sorry I meant "that's a really nasty corner case", no slur on you intended. I would much rather that these issues were brought up now, than submitted as DR's later! > >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. In this case, I'm under the impression we are > trying to implement something within the existing language that should > actually be a built-in operator. I think the question is: do we need > is_convertible<> for generic programming? If so, can it be implemented > in current C++? No? Then make it an operator. I appreciate the > philosophy of C++ of avoiding putting in the core language what can be > implemented in the library but, hey, if it can't then you can't! :-) > > Maybe half-ways between a built-in is_convertible operator and a > library implementation are possible: e.g. you could have two > non-member template functions: > > namespace std { > > typedef char (&no_type)[1]; > typedef char (&yes_type)[2]; > > template <typename T> > struct identity { typedef T type; }; > > template <typename To> > no_type is_convertible(...); > > template <typename To> > yes_type is_convertible(typename identity<To>::type); > > } > > > This is already a useful facility to check convertibility of > expressions. Once you have it, you can use it for types too as long as > you have an operator that, given a type, gives you the expression to > pass to std::is_convertible > > > std::is_convertible<To> ( expression(From) ) > > > That's just a rough idea, of course. > Also, it would be nice to have, as syntactic sugar, a shortcut for > testing sizeof(std::is_convertible...) against sizeof(no_type) and > sizeof(yes_type), e.g.: > > is_true ( std::is_convertible(char) (expression(int)) ) > > > But then you already have two new operators (ok, is_true isn't > strictly necessary, and could be a macro ;-)), so why not making > is_convertible an operator instead? It remains however that is_true > would be handy in itself, and that I would like no_type and yes_type > to be standardized. I don't think these solve anything, there are five cases that need to be considered: No conversion is possible. A conversion is possible. The target type is not an object or reference type - the code must not compile. A conversion is possible but would use a non-public constructor - the code must not compile. A conversion is possible but would use a non-public conversion operator - the code must not compile. A conversion is possible but is ambiguous - the code must not compile. It's the last three cases (and exactly which situations produce them) that we are agonising over. It doesn't matter whether you use a class template or an operator, you can't make these cases do anything meaningful. Perhaps I should have said "ill formed" rather than "undefined", I'm still learning the right terminology... > >Clearly is_convertible<T,U>::value must have a single value under the one > >definition rule, so there can be no ambiguous context-sensitive answers. > > > >Thanks for bringing these up, I'll try and produce some better wording over > >the weekend, and then I'll see if you guys can shoot it down again :-) > > Well, as I said the intent was quite the contrary than being > destructive. I'll look forward for the new wording :-) Again, thanks for the all comments. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost