<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">&lt;<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>&gt;</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">&gt; Building on Haravikk&#39;s suggestion:<br>
&gt;<br>
&gt;     1. Make methods and classes final by default<br>
<br>
That&#39;s a serious problem for Swift resilience—it&#39;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&#39;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&#39;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 &quot;before&quot; method&#39;s super call or after an &quot;after&quot; method&#39;s? Too bad, the guy who wrote the superclass said &quot;no&quot;.)<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 &quot;before&quot;/&quot;after&quot; 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&#39;s tremendously overengineered, insufficiently motivated, and fits poorly into Swift&#39;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>