On 5/10/17 11:15 AM, Dicebot wrote:
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?
I prefer the first one. The reason is simply because it doesn't require
any new grammar. The override requirement is already a protection
against changing base class. In this case, we have two possible outcomes:
1. The base class finally implements the method and removes future. In
this case, the derived class continues to function as expected,
overriding the new function.
2. The base class removes the method. In this case, the override now
fails to compile. This is not as ideal, as this does not result in a
version that will compile with two consecutive versions of the base. But
there is a possible path for this too -- mark it as @deprecated @future :)
-Steve
