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!
