Re: RFA: Deprecate C++ options

[Mark Mitchell <mark at codesourcery dot com>]

--On Thursday, September 06, 2001 11:41:37 AM +0100 Nathan Sidwell 
<nathan@codesourcery.com> wrote:

> Hi,
> There are several flags which change the language compiled by G++.
> It's difficult to support any particular combination of them. See
> http://gcc.gnu.org/ml/gcc/2001-04/msg01243.html for an example.
>
> I'd like to deprecate and then remove them from g++ asap. I
> suggest deprecating them in 3.1 and removal in 3.2
>
> Support of old ARM conformant code
> -fno-for-scope
> 	the for loop variable's scope extends beyond the loop
> -fcheck-new
> 	cope with operator new returning null, rather than throwing
> 	The interaction of this with the builtin operator new and
> 	-fno-exceptions confuses users.
> -fno-operator-names
> 	don't have `and' `or' etc as keywords

I agree.  All of these will cause minor headaches for people working
with very old code, but all are easily fixed, and none have been
considered correct C++ for ages, and all would simplify the compiler.
On that basis, -fno-operator-names is the least compelling; supporting
that does not cost much at all.

> Bug workaround. Are there many access control bugs? I can't recall any
> in GNATs off hand.
> -fno-access-control
> 	don't check access

The new parser fixes many of the remaining bugs -- but there's no guarantee 
yet that it will be in 3.1.  In general, the bugs that I know of with the
new parser are a subset of those with the old, and they are of the
flavor where we do not report errors that we should, not vice versa.

So, I agree with deprecating this as well.

>
> Unknown.
> -fno-elide-constructors
> 	don't elide copy ctors What is the rationale for this? I'd've
> 	thought -O0 would be a suitable switch for this.

Agreed.  Any code that depends on this is unbelievably fragile.

> No doubt this is an SC issue, perhaps Mark or Jason could raise it there?

I don't know that removing these switches is an SC issue, but it might
be.  Let's see if we can get developer consensus first.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com