DIP 1007 Preliminary Review Round 1

[Leandro Lucarella via Digitalmars-d]

On Tuesday, 25 April 2017 at 12:33:44 UTC, Steven Schveighoffer 
wrote:
> Really, what you are doing is reserving the overload spot. In 
> cases where the overload would have selected your local 
> function, then you should get no warning (as the additional 
> symbol won't conflict). In cases where your function conflicts 
> with a newly-reserved base class function, then the warning 
> should be that you will eventually need to include the 
> `override` keyword.
>
> 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? If you put 
> override on foo, it's not really overriding anything as 
> Base.foo doesn't really exist (right?). Basically, we need a 
> way to write Derived such that it works with both the @future 
> reserved Base.foo, and the permanent Base.foo. With 
> deprecation, the path is clear, you just stop using that 
> symbol. This is not as clear.
>
> If adding override is allowed even when base symbol doesn't 
> really exist, that might work, but it needs to be explicit in 
> the DIP.

This is a very good point. We'll send a PR with a proposed 
solution to address this issue soon.

Thanks!