<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">So that is what it boils down to then. So you believe that this change is necessary so that:<div class=""><br class=""></div><div class="">class ContreteClass: SuperClass, AbstractProtocol { … }</div><div class=""><br class=""></div><div class="">becomes</div><div class=""><br class=""></div><div class="">class ContreteClass: AbstractClass { … }</div><div class=""><br class=""></div><div class="">?</div><div class=""><br class=""></div><div class="">It is my humble opinion that if this is the core advantage of this proposal, it should not be accepted. This is a major change in the language, not just a small new feature to be added, and if it can be done with existing functionality (like protocols) then at least it should be postponed for future review for Swift 4. For the sake of discussion lets say this does has its advantages, lets put that in the context of Swift 3 development.</div><div class=""><br class=""></div><div class="">Pros:</div><div class="">- Easier Syntax</div><div class=""><br class=""></div><div class="">Cons:</div><div class="">- Already possible with a little different syntax. Nonetheless, if you use protocols properly the EXACT functionality can be achieved. The compiler WILL force you to write an implementation for a protocol.</div><div class="">- Again, protocols are shared between structs and classes, its a syntax unifier to use protocols. With a language that uses structs for 97% of its Standard Library, protocols seem as a better idea for the sake of clarity and unity. Each new feature has o be learned by all Swift programmers. Why add a different syntax (that has to be learned) for existing functionality, when protocols are shared between value and reference types?</div><div class=""><div class="">- Will disrupt stabilization of Swift 3, should be postponed for Swift 4 since its a mejor language change</div><div class=""><br class=""></div><div class=""></div><div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica;  font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class="Apple-tab-span" style="white-space: pre;">I</span>f you could provide an example of functionality this proposal will implement, that cannot be achieved currently in Swift, then I believe it would be worth it to introduce such a major new syntax, only for classes.</div><div style="color: rgb(0, 0, 0); font-family: Helvetica;  font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span class="Apple-tab-span" style="white-space: pre;"><br class="Apple-interchange-newline">        </span>Coleman,</div><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Mar 3, 2016, at 4:26 PM, Evan Maloney &lt;<a href="mailto:emaloney@gilt.com" class="">emaloney@gilt.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">On Mar 3, 2016, at 4:21 PM, Matthew Judge &lt;<a href="mailto:matthew.judge@gmail.com" class="">matthew.judge@gmail.com</a>&gt; wrote:<br class=""><br class="">Not necessarily commenting for or against abstract classes, but the following logic confuses me:<br class=""><br class="">"ONLY an abstract class, ON ITS OWN, can force concrete subclassers to provide an implementation for a given thing.<br class=""><br class="">Protocols can't do this, because if you forget to declare conformance with the protocol, the compiler can't enforce anything. This pushes what could be caught at compile-time to a runtime (potentially crashing) problem."<br class=""><br class="">What is the difference between forgetting to declare conformance to a protocol and forgetting to subclass an abstract class? An abstract class, ON ITS OWN, cannot force a class to do anything unless that class declares itself a subclass of the abstract class.<br class=""></blockquote><br class="">It's the difference between forgetting to do two things and forgetting to do just one.<br class=""><br class="">Let's say I have a framework that requires me to supply a subclass of Foo to do something useful.<br class=""><br class="">With abstract classes, I just need to subclass Foo, and the compiler tells me what implementations I need to provide.<br class=""><br class="">With the protocol-based "solution" being proposed, I need to subclass Foo *and* I need to remember to declare conformance to FooProtocol. Then and only then can the compiler enforce anything.<br class=""><br class="">2 != 1<br class=""><br class=""></div></div></blockquote></div><br class=""></div></body></html>