<div dir="ltr">huge +1 from me. </div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 5:16 PM, Marc Knaup via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Default behavior would require something like "unrequire" which seems odd.<div><div>Also this would break a lot of existing code and migration can't be done automatically.</div></div></div><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 11:04 PM, Tino Heth via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A huge +1 on this — I'd actually go one step further and propose to make it the default behavior:<br>
Calling super rarely hurts, and it would be easier to find a better name for the attribute ;-) (maybe "replaceable"…)<br>
Additionally, it is one step in the right direction for those who think "final" should be default (if there is any good reason to prefer final over requires_super, I haven't seen it yet).<br>
<br>
Instead of enforcing the call to super, it would be possible to automatically run the super implementation after (or before) the overriding method (unless it is explicitly called).<br>
<div><div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=X7Cgx-2BytehPZNV08Ma8u6QzesuSJsCfcYBYxecjdpX0oO9a3hhhQmLtxiRa4-2BEqTE2P52bmHvswEgCxCQue50SBY9R74VMcrPoXZ0gbwcrpfutjkbY8mFCnVwv8Vud2kxkCkrVyPFb58OeOf1h-2BMeJqM7k1xmH0yXNZfyztCNjd4feUoJDVnLgQYVVc6-2F-2FknYs9CIevIq8L3ZZUA0CaNwRPwcy4Fm4NwaikPgOvwn0E-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>