[swift-evolution] Replace the override keyword by 'extend' and 'replace' or add an annotation like @SuppressSuperCall
howard.lovatt at gmail.com
Tue Feb 16 21:13:21 CST 2016
Comments in-line below.
On 17 February 2016 at 12:22, Brent Royal-Gordon <brent at architechies.com>
> > Building on Haravikk's suggestion:
> > 1. Make methods and classes final by default
> That's a serious problem for Swift resilience—it's not safe to change a
> public class from final to non-final because that would break devirtualized
> calls in other modules. Whatever the default is, it needs to not break
If a class/method is final it can be made virtual, but not vice versa.
Therefore the default is best as final since you can change your mind
later. Whereas a virtual declaration you are stuck with.
> Overall, I don't like this proposal for several reasons:
> - It conflates several different features—final, abstract, super call
> requirement, super call location—into a single set of annotations.
Yes. There is some discussion of splitting out abstract. Could also split
out final. However you wouldn't want a solution for final or abstract that
stopped you from later adding super constraints if people decided they were
> - It violates the usual grammar of Swift declarations by attaching
> particular modifiers directly to the keyword, disrupting the usual flow of
Different syntaxes have been discussed, mainly `@super(option) override
func name()` and `override(option) name()`, both have precedence in Swift,
e.g. annotations like `@noexcape` and options on annotations and
constraints on visibility like `private(set)` respectively.
> - It not only supports, but actively encourages, placing extremely heavy
> constraints on subclass implementations. (Want to put a logging statement
> before a "before" method's super call or after an "after" method's? Too
> bad, the guy who wrote the superclass said "no".)
A similar discussion has occurred re. pure functions. It might be possible
to say no mutating stored properties before/after the super call in a
"before"/"after" method respectively. This would require some careful
> In general, this proposal seems like it's tremendously overengineered,
> insufficiently motivated, and fits poorly into Swift's syntax.
Not the first time this sort of discussion has come up on Swift Evolution -
therefore there is some interest.
> Brent Royal-Gordon
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution