[swift-evolution] Replace the override keyword by 'extend' and 'replace' or add an annotation like @SuppressSuperCall

[Howard Lovatt]

Comments in-line below.

  -- Howard.

On 17 February 2016 at 12:22, Brent Royal-Gordon <brent at architechies.com>
wrote:

> > 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
> things.
>

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
still useful.


> - It violates the usual grammar of Swift declarations by attaching
> particular modifiers directly to the keyword, disrupting the usual flow of
> modifiers-keyword-name-type.
>

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
consideration though.


>
> 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
> Architechies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160217/f12f95f4/attachment.html>