Thoughts about deprecation
smjg_1998 at yahoo.com
Sat Feb 11 18:21:39 PST 2012
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
(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
(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
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?
More information about the Digitalmars-d