Re: [C++] deprecate overload resolution extension?

[Joe Buck <jbuck at synopsys dot COM>]

> We will be forcing the disambiguation; in the C++ frontend, pedwarns are
> errors by default.  But I would like people to be able to build code that
> relies on this with -fpermissive; again, I put this extension in because
> things were breaking without it (though I don't remember what).

I wouldn't be surprised if the test case that caused you to do this was
some customer who had code that had never been compiled by any compiler
other than g++.  At *minimum*, if the standard rules say it's ambiguous,
we need to report a warning.

C++ users *like* the strong typing.  You aren't doing anyone a favor by
failing to diagnose errors, at least in most cases.

Now, it is true that the overload resolution rules have changed over time,
so it would be reasonable to me to allow (WITH WARNINGS) cases that were
non-ambiguous according to the ARM but ambiguous now.  But no version of
C++ ever had the rule that one should prefer the first overload.  Speaking
as someone who must develop with many C++ compilers, it is greatly
annoying to me if g++ "knows" something is wrong and refuses to say so
unless the (unusable to me in most cases) -pedantic option is given.

I think that -permissive should only be to support wrong but widespread
practices, like things legal and C and not in C++, such as the bad X11R6
headers.  It might also be for allowing things blessed in the ARM but
forbidden now, like initialization of non-const references with
non-lvalues.  The idea is to permit something that was once documented
as correct, so old code can be built.