On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer
wrote:
Actually, that brings up a problem with this, what is the
mechanism to say "maybe override"? Let's say you have:
// in imported library
class Base
{
void foo() @future;
}
// in user library
class Derived : Base
{
void foo() {...} // triggers warning
}
What is the next step the user has to take to remove the
deprecation warning, but still have valid code?
Right now I have two possible approaches in mind.
One is to simply allow overriding `@future` symbol which doesn't
require any extra stuff but can be viewed sub-optimal because it
couples two loosely related concepts and would require special
cases in how future symbols are handled inside compiler (they
stop being completely ephemeral).
Other would be an accompanying DIP to be able to specify
`overide(strict)` (default, same as plain `override`) vs
`override(optional)` to be able to define methods that may or may
not override base one, with no specific relation to `@future`.
I don't have any hard opinion on the matter of my own, what do
you think?
