On 21/03/2013 07:51, Jonathan M Davis wrote:
On Thursday, March 21, 2013 08:29:28 deadalnix wrote:
Wouldn't that trigger bunch of false warning on legitimate
overloaded opSomething ?
I'm not sure that overriding a deprecated function triggers a deprecation
warning, but regardless, for opEquals and opCmp, that wouldn't be a problem,
because all classes would be being changed so that their opEquals and opCmp
don't take Object, so the deprecation warnings would be a _good_ thing.
The problem really is that the D runtime references these methods of
Object. So the process would be something like this:
(a) reimplement AAs using templates
(b) rewrite any other code that depends on these methods of Object
(sorting out TypeInfo might be tricky)
(c) and then deprecate these methods
Code that defines opEquals(Object) or opCmp(Object), either instead of
or as a call to a class-specific version, will still work during this
phase-out. But I'm inclined to agree that trying to override a
deprecated method without declaring the override as deprecated should
trigger a deprecation error.
It would probably be more of a problem for toString and toHash
though, since they don't take arguments. Deprecating them won't work
if overriding them triggers deprecation warnings, and the fact that
you'll be forced to override them as long as they're in Object and
then won't be allowed to once they're out of Object will probably
mean simply removing them from one release to another and forcing
everyone to immediately change their toHash and toString methods so
that they don't break.
<snip>
Yes, it does seem that we would need something to accommodate this.
Maybe a way to mark a deprecated method so that it can be overridden
without the override attribute, but overriding it with the override
attribute will trigger a deprecation error. But would this feature get
any real use after we've got rid of these methods from Object?
Stewart.
