This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]