<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hello Joe,</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">A few quick questions came to mind after reading your answer, if you do not mind. You mention protocols falling short in some areas to provide part of the functionality that abstract classes provide, but is the concern that we may be making protocols harder and harder to pickup and use correctly by giving them so much responsibility?l</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Also, do you think the lines between structs, protocols, and classes going to blend even more with these and other similar changes? </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">(Although only tangentially related perhaps...) Did the core team stated what they planned to do about pitfalls with dispatching and protocol extensions with default method in extensions being statically dispatched and actual method resolution then being dependent on the type of the reference rather than the instance the reference is pointing at? Is this area being addressed in Swift 3 at all?</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Thank you in advance for your answers :).</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Kind Regards,</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Goffredo</div><div id="AppleMailSignature"><br>Sent from my iPhone</div><div><br>On 7 Mar 2016, at 18:00, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii">The review of <span class="" style="font-family: 'Helvetica Neue';">SE-0026 "Abstract classes and methods"</span> ran from February 26...March 4, 2016. The proposal has been <b class="">deferred </b>from Swift 3. Discussion centered around whether abstract classes fit in the direction of Swift as a "protocol-oriented" language. Beyond any religious dogmas, Swift intends to be a *pragmatic* language that lets users get work done. The fact of the matter today is that one of Swift's primary target platforms is the inheritance-heavy Cocoa framework, and that Swift 2's protocols fall short of abstract classes in several respects, including:<div class=""><br class=""></div><div class="">- Protocols can require conforming types to provide properties, but extensions cannot instantiate storage into conforming types. Every conforming type must today satisfy a protocol's storage requirements itself.</div><div class="">- Type erasure is easier to accomplish using abstract base classes with generic subclasses. Protocol existentials today only support all-or-nothing type erasure, and don't support protocols with associated type or Self constraints at all.</div><div class="">- Protocols don't support language enforcement of separate implementor and user interfaces, since all of a protocol's requirements must be as visible as the conformance. An abstract base class can expose private or internal abstract requirements to its implementation subclasses while exporting a different interface for external users.</div><div class="">- Protocol extensions can provide default implementations, but there's no equivalent to 'super.' today for a concrete implementation to be able to chain up to a default implementation.</div><div class=""><br class=""></div><div class="">Unfortunately, the core team is currently bandwidth-constrained and can't immediately participate to the degree we'd like in the design of this important feature. Furthermore, "completing generics" is one of our primary goals for Swift 3, and proposals for addressing many of the above limitations with protocols are in various stages of discussion and design. We'd like to revisit this feature once the core goals of Swift 3 have been addressed, so we can more accurately consider its value in the context of a more complete generics implementation, and so we can address the finer points of its design.</div><div class=""><br class=""></div><div class="">Some things to consider for future revision:</div><div class=""><br class=""></div><div class=""><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""></p><blockquote type="cite" class="">An abstract class cannot be instanciated. </blockquote><p></p></div><div class="">This can be prevented in cases when `AbstractClass(...)` is statically spelled, but the behavior of abstract class metatypes must be specified. Is `let classObject: AbstractClass.Type = AbstractClass.self` allowed? Does `let classObject = _typeByName("Module.AbstractClass")` work? If not, then the abstract class object cannot be used for metaprogramming or generic argument binding purposes. If it can be, then there's a static safety hole, since `classObject.init(requiredInitializer:)` would have to dynamically fail if `classObject` refers to an abstract class metatype.</div><div class=""><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""></p><blockquote type="cite" class=""><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">When declaring an abstract property, you must specify which methods must be implemented : get, set, didSet, willSet. </p><p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">If you do not specify anything, only setter and getter are made abstract as below : </p><div class="highlight highlight-source-swift" style="box-sizing: border-box; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><pre style="box-sizing: border-box; overflow: auto; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; padding: 16px; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-wrap: normal; word-break: normal;" class=""> abstract <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">var</span> url <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">:</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">String</span></pre></div></blockquote></div><div class="">Only 'get' and 'set' are of interest for a property's interface. For consistency with protocol requirements, abstract properties should probably require an explicit '{ get }' or '{ get set }' declaration to indicate whether mutation is expected.</div><div class=""><br class=""></div><div class="">-Joe</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>