<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=""><div><blockquote type="cite" class=""><span style="font-family: 'Helvetica Neue';" class="">- What is your evaluation of the proposal?</span><br class=""></blockquote><div><br class=""></div><div>I could not more strongly support the proposal to add abstract classes, functions and properties to Swift.</div><div><br class=""></div><div>None of the proposals involving protocols as a solution to this have addressed the fundamental issue:</div><div><br class=""></div><div>*ONLY* abstract classes ON THEIR OWN allow the compiler to enforce providing an implementation for a given function.</div><div><br class=""></div><div>For example -- and not picking against the author of this, it's just the most recent example to grace my inbox:</div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: 'Helvetica Neue';" class="">I am against the proposal because I feel it goes against the Protocol Oriented Programming patterns found in the Swift Standard Library. Current protocol functionality can provide a solution for the given example. If a protocol property is not implemented, the compiler will not let you compile. </div></div></div></blockquote><div><br class=""></div><div>This does not address the fundamental concern of abstract classes.</div><div><br class=""></div><div>Yes, a protocol will force you to provide an implementation. However, a protocol *by itself* cannot force the implementor of a class to provide an implementation unless that class declares itself in conformance with that protocol.</div><div><br class=""></div><div>ONLY an abstract class, ON ITS OWN, can force concrete subclassers to provide an implementation for a given thing.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>Abstract classes enforce a requirement that a given portion of the class hierarchy provide an implementation of X.</div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: 'Helvetica Neue';" class="">• Is the problem being addressed significant enough to warrant a change to Swift?</div></div></div></blockquote><div><br class=""></div>Yes.</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: 'Helvetica Neue';" class="">No, protocols implement this functionality, but with a different syntax. There is no lacking or additional functionality this proposal provides.</div></div></div></blockquote><div><br class=""></div>No, protocols *do not implement* this functionality. They provide something else, and are orthogonal to the class hierarchy.</div><div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: 'Helvetica Neue';" class="">• Does this proposal fit well with the feel and direction of Swift?</div></div></div></blockquote><div><br class=""></div><div>Absolutely. Swift is about safety, about letting the compiler perform safety checks. ONLY abstract classes allow the compiler to enforce that an implementor of a given subclass has provided an implementation for a given function.</div><div><br class=""></div><div>Solutions that require the use of protocols can only be checked for correctness if the implementor of the subclass in question ALSO declares conformance to the protocol.</div><div><br class=""></div><div>In other words, a protocol-based solution can only be checked by the compiler if the developer does 2 things correctly (declares protocol conformance and provides an implementation), whereas abstract classes allow the compiler to perform checks as long as the developer does 1 thing (subclass a given class).</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: 'Helvetica Neue';" class="">No. It goes against protocol oriented programming.</div></div></div></blockquote><div><br class=""></div>Swift isn't ONLY about protocol oriented programming. Classes are here for a reason, and they should not be relegated to second-class status where people refuse to consider class-only functionality just because the concept can't be shoehorned into something protocol-related.</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: 'Helvetica Neue';" class=""> Furthermore, this is only for classes, structs are being excluded in this case. I feel that with most of the standard library being implemented as structs, this is not acceptable.</div></div></div></blockquote><div><br class=""></div><div>Rather than reject this proposal because "this is only for classes," perhaps recognize that this is only for classes PRECISELY because this type of problem--the one that abstract classes addresses--only occurs with a class hierarchy.</div><div><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: 'Helvetica Neue';" class="">• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</div></div></div></blockquote><div><br class=""></div><div>C++ and have found them EXTREMELY useful. This proposal is in line with that.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: 'Helvetica Neue';" class="">• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div></div></div></blockquote><div><br class=""></div><div>I've been following this discussion very closely, and before I realized there was already a proposal in the queue for abstract classes, I also wrote a similar proposal:</div><div><br class=""></div><div><a href="https://gist.github.com/emaloney/d0b5bf7dd831d4f7415c" class="">https://gist.github.com/emaloney/d0b5bf7dd831d4f7415c</a></div><div><br class=""></div><div><br class=""></div><div><br class=""></div></div></body></html>