On Thursday, 11 May 2017 at 00:04:52 UTC, Steven Schveighoffer
wrote:
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
Sounds reasonable. I'll submit an update to the DIP.
