This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [C++] deprecate overload resolution extension?
- To: gcc at gcc dot gnu dot org
- Subject: Re: [C++] deprecate overload resolution extension?
- From: Fergus Henderson <fjh at cs dot mu dot oz dot au>
- Date: Wed, 28 Feb 2001 14:33:49 +1100
- References: <20010228001638.E9B89F289E@nile.gnat.com>
On 27-Feb-2001, dewar@gnat.com <dewar@gnat.com> wrote:
> <<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).
> >>
>
> Well that's not very convincing :-)
>
> This "extension" clearly causes an ambiguous expression to be treated
> as unambiguous by taking what is (in terms of the standard) an arbitrary
> choice.
Only if `-fpermissive' is enabled.
> Perhaps a convincing example would change people's minds. It seems like
> any language extension should be thoroughly documented, with motivating
> examples before it is implemented.
I agree with that principle. However, in the case of a language
extension which is already present in previously released versions of
gcc, and where it is decided that the extension is not a good idea
after all, then I think it should only be phased out *slowly*. By all
means issue a warning or even an error by default, but where feasible,
it would be better if there is an option to turn the error back into
just a warning, so that old code will still work.
`-fpermissive' seems to me like a reasonable name for that option.
But if `-fpermissive' has other uses, then some other option name,
e.g. `-fbackwards-compat', could be used.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.