[Issue 9289] [Regression 2.061] Had been deprecated language features are enabled again in default

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=9289



--- Comment #8 from Jonathan M Davis <jmdavisProg at gmx.com> 2013-01-11 19:12:02 PST ---
Honestly, I think that it would be great in general to be able to distinguish
between soft deprecation (warn about it) and hard deprecation (make it an
error), but I can also understand not wanting to add that sort of complication
to the feature, especially since it's a feature that should be needed
relatively rarely. And if you only get one of the two, soft deprecations are
far less disruptive, and I think that we were right to make deprecated warn by
default, but it does pose a bit of a problem for the language features.

For that, I think that there are two basic approaches which make sense:

1. Make deprecated work as it has been for language features and use normal
warnings when we want to "soft" deprecate a language feature, which is exactly
what we have been doing. But we keep the new behavior (warn by default) for the
deprecated keyword.

2. Make at least some of the currently deprecated language features into errors
rather than have them be deprecated. Then have deprecation for language
features be exactly the same as it is for the deprecated keyword, so some
features end up being errors which can't be disabled, and some become warnings
rather than errors by default. If we go that route, we should probably also
think about making some of the current warnings into deprecation warnings (e.g.
when skipping the use of override).

The second approach would probably be the cleaner of the two, but it does mean
that we lose the ability to give an error for language deprecation by default
and still allow for the feature to be used. On the other hand, using
deprecation warnings instead of normal warnings for deprecating features would
be great, because then people don't have to use -w or -wi to see them. And that
would make doing stuff like deprecating delete much smoother, since it would
ensure that anyone using it got bugged about it rather than just those folks
who compile with warnings enabled. It also keeps its behavior in line with the
deprecated keyword, which would probably be a good idea if we can reasonably do
so.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------