<div dir="ltr">Comments in-line below.<div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 17 February 2016 at 12:22, Brent Royal-Gordon <span dir="ltr"><<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> Building on Haravikk's suggestion:<br>
><br>
> 1. Make methods and classes final by default<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Overall, I don't like this proposal for several reasons:<br>
<br>
- It conflates several different features—final, abstract, super call requirement, super call location—into a single set of annotations.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- 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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- 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".)<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
In general, this proposal seems like it's tremendously overengineered, insufficiently motivated, and fits poorly into Swift's syntax.<br></blockquote><div><br></div><div>Not the first time this sort of discussion has come up on Swift Evolution - therefore there is some interest.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</font></span></blockquote></div><br></div></div>