C++ extension "cast-as-lvalues": time to deprecate?

[Joe Buck]

On Fri, 2003-05-09 at 14:00, Joe Buck wrote:
> > There's a somewhat different issue here, though: what about strictly
> > conforming programs that malfunction because of the extension, in a way
> > that is surprising to the user?  Do we have to keep miscompiling them
> > for two more releases?
 
On Fri, May 09, 2003 at 04:21:12PM -0700, Mark Mitchell wrote:
> I think not.  I think we can add a warning in 3.3.1, and remove the
> feature in 3.4.

But what, exactly, are we warning about?  Consider the following program:

--------------------------------------
#include <iostream>

void foo(int&) {
    std::cout << "foo(int&) called\n";
}

void foo(const int&) {
    std::cout << "foo(const int&) called\n";
}

int main(int, char**) {
    unsigned u = 0;
    foo((int)u);
}
--------------------------------------

Here, because GCC is making the cast an lvalue, the program incorrectly
calls foo(int&) instead of foo(const int&).  But there's nothing wrong
with the program, there is only something wrong with gcc.

We could warn that GCC has used the cast-as-lvalue extension, but how, then,
does the user fix the warning if the user really needs to make the distinction
between a const and a non-const reference?

I thought a bit about the idea of trying to make the extension work only
in programs that would otherwise have an error, but it's tricky.  Uses
of casts would have to be resolved twice, once according to the standard
and then, if there's no match, again according to the extension.
 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com

-- 
Q. What's more of a headache than a bug in a compiler.
A. Bugs in six compilers.  -- Mark Johnson