On Sat, 25 Jan 2003 12:17:18 -0000, "John Maddock" <[EMAIL PROTECTED]> wrote:
>> 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) Yes, but the special conversion is from const char[N] to char*, not const char*. >Absolutely, sorry I meant "that's a really nasty corner case", no slur on >you intended. It's all right for me :-) [...] >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... Yes, I agree that they should be ill-formed. The problem is, as we have repeatedly pointed out, that the template implementation isn't adequate if is_convertible<>::value may depend on the context, because of possible violations of ODR. A built-in operator would solve the problem. Also, if you stick to expressions as source, the function templates seem to work (unless we discover some other problem with them too). Again, I like the approach to not put in the core language facilities that can be implemented with normal code but the order is: first I see what I want to get, then I see if it can be implemented. Here we seem to do the inverse: we see what can be done in current C++, and if it is not enough (because I can't do access checking) we are contented anyway. Seems a surrogate to me. Genny. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
