Re: RFA: Deprecate C++ options

[Nathan Sidwell <nathan at codesourcery dot com>]

Thanks for all the input on this. [Jason, I thought you were on
holiday - get back to having a break!]

> In general, I feel strongly that we should accept old code with a pedwarn
> if at all reasonable.  If that is for some reason not feasible, such as a
> conflict between old and new semantics, then I can accept breaking old code
> with helpful comments to suggest how the user ought to fix their code.  I
> am against just removing previous functionality and leaving users to wonder
> why their code doesn't work anymore.
Whilst, in general I agree with you, at what point does it become difficult
to support the old semantics? That depends on 'random' future development
directions. For instance, as you know, the implicit typename extension is
going away because of its implementation difficulty and conflict with the
std. Breaking non-conformant code in one go might be better than continual
breakage at each new gcc release.

Bernard Dautrevaux wrote:
> I think we must first warn the users that old for scope will soon no more be
> supported, then (in 3.2?) change that to an error (with explicit mention of
I did mean this - first issue a 'this is deprecated and will be removed'
warning, and then in some later release remove it.

> > -fcheck-new
> I think the confusion is that -fno-exceptions should set flag_check_new,
> and it currently doesn't.  But I haven't seen any messages about this.
plus what should
	foo = new T ()
call? operator new (size_t) throw (bad_alloc), or operator new (size_t,
no_throw_t const &) throw ()? What should a failing dynamic_cast <T &> (foo)
do? probably some other things I've not realised.

> It seems to me that you want to remove functionality just because you don't
> think it's necessary.  I disagree with that.  IMO, functionality should
> only be removed if it's a significant maintenance burden.  Why should we
> gratuitously make users' lives more difficult?
Not because they're unnecessary, but because they increase the maintainance
burden. In a conforming C++ world, they are unnecessary. Is it a worthwhile
and acheivable goal to get there? Of the current maintainers Jason has the
longest historical perspective on g++. It was your query about my
recent patch to compound statments and -fno-for-scope that reminded
me to ask about deprecating these things. 

The g++ developer resource is time constrained, we have to prioritize and 
ration it. To paraphrase a floating point saying,
	std conformance, backwards compatibility, bug fixes: Pick *two*

Tim Hollebeek wrote:
> If people would rather combine these options into -lang=c++-arm, to
> reduce the number of combinations of options that is possible, then do
> that.  But don't succumb to the silly argument that it is no longer
> necessary to produce a compiler that knows how to compile this

With a clean slate, this would have been a sensible idea. Implementing
that now would have a number of issues which might make it unrealistic.
1) old code would need its build/configure/make files updating to specify
-lang=c++-arm, rather than -fno-for-scope .... If you have to touch the
package anyway, why not fix the problem properly?
2) I suspect the ARM may be ill-defined in exactly the areas where
traditional c++ differs from std c++.

George Garvey wrote:
> Thanks from one of those who will be caused minor headaches (probably
> several day's work if you do this and one wants to use a recent compiler)
> for working with very old (unmaintained but essential) code (consisting of
> thousands of line of now incorrect C++), but all are easily fixed (with
> hours of work that will need to be done by every single individual using
> the unmaintained code).
Why is a popular, essential package unmaintained? It'll die of bit rot from
more sources than compiler language changes. This is not to denigrate
your minor headaches, but which would you prefer.
a) one headache on one compiler upgrade (with advanced warning in a previous
upgrade that that was going to happen)
b) minor headaches on compiler upgrades when 'oops, we could not keep
backwards compatibility here' happens?

In summary it seems that all developers, bar Jason, would like a std
conformant compiler only (Though Jason's opinion carries a lot of weight)
Users, however, are against the idea or losing backwards compatible
options.

nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org