DIP 1007 Preliminary Review Round 1

[Steven Schveighoffer via Digitalmars-d]

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