On 02/12/2012 03:21 AM, Stewart Gordon wrote:
Deprecation is a nice feature. There doesn't seem to be any doubt about it.
But it's by no means perfect, compiler bugs aside. I have identified
these ideals of deprecation:
(a) Code that compiles without -d compiles and behaves the same with -d.
(b) Code that compiles without -d compiles and behaves the same if all
entities declared as deprecated are removed from the code.
(c) Code that compiles with or without -d compiles and behaves the same
if all deprecated entities are de-deprecated.
(d) Code that compiles without -d either compiles and behaves the same,
or fails to compile at all, if any entities are newly deprecated (i.e.
does not silently change its behaviour).
(e) Validity checking through compile-time reflection is always
consistent with whether the compiler actually accepts the code.
(OK, so the switch used to enable deprecated entities might vary between
brands of compiler, but I've used "-d" here for simplicity.)
But these ideals cannot all be satisfied at once.
The main reason for this seems to be compile-time reflection. My
experiment (under DMD 1.071 and 2.057) shows that an IsExpression
evaluates to false if the compiler would reject it because of
deprecation. This satisfies ideals (b) and (e), but violates (a), (c)
and (d).
If we changed it to evaluate to true even if compiling without -d, then
it would satisfy (a), (c) and (d), but violate (b) and (e). Moreover,
when/if we get -di
http://d.puremagic.com/issues/show_bug.cgi?id=7041
what would it do if we have deprecation-dependent behaviour?
But deprecated entities aren't always treated as though they're not
there if compiling without -d. For example, deprecated functions take
part in overload resolution. This is necessary in order to satisfy (a),
(c) and (d). Though it doesn't seem to make any difference to (b) or (e).
Maybe DDB is useful at times. The use case that comes to mind is
suppressing the handling of a deprecated property as part of a
non-deprecated method. But still, is accidentally programming DDB in
something that needs to be guarded against? Or do we just accept DDB as
a natural, unpreventable consequence of reflection?
I'm not sure whether all ideals would be satisfied in the absence of
CTR, or if there are other aspects of D that prevent it from being so.
I suppose the overall point is: Is the current compiler behaviour the
best that can be done? Which ideals of deprecation do we really need to
follow, and which can we do without?
Stewart.
I think (e) is not an ideal of deprecation. If a feature is deprecated,
then checking whether it compiles should be deprecated too.
