On Thu, 2007-10-25 at 07:59 -0500, Gabriel Dos Reis wrote: > 'deprecated' in the standard does not carry much semantics weight, > unless the feature is also removed. But, even then we would have to > worry about existing codes that were written using the feature. That > is one of the reasons why I'm unsympathetic to proposals before the > committee to `deprecate' things.
I think this is the wrong idea. Deprecated does carry a lot of weight. It allows a new compiler without a legacy to elide the feature and specify it is ISO compliant 'minus' the deprecated features, which is quite different from 'non-compliant'. In particular, for a product like gcc it means a switch like --no-deprecated-features can be added and then used by a client without risking 'all bets are off since the compiler isn't conforming'. Note I'm entirely agreeing with your the first line I quote from you above, but questioning lack of sympathy with proposals to deprecate features considered undesirable. A shop writing new code may tell programmers not to use deprecated features because the committee of 'experts' thinks they're undesirable, and enforce that with a switch, thereby attempting to enforce an improvement of code quality, and i would not laugh at such a policy, so I think 'deprecating' features really can have positive impacts. In fact if I may cite a REAL example from my own code in the last few days .. gcc 4.2 is now complaining about 'conversion of string literals to char* is deprecated'. Thanks you gcc! I have fixed all the examples. I believe my code quality is now better. By gcc 5.0 I expect and hope this deprecated feature will cause a hard error unless I specify a --allow-deprecated-features type of switch. Deprecation is a migration path -- isn't that what C++ is all about with respect to C? -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
