DIP 1007 Preliminary Review Round 1

[Dicebot via Digitalmars-d]

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?