<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Extremely strong +1 from me on this proposal. It is the best default for many, many reasons (stated in the proposal and in Austin's review). It improves safety, facilitates and encourages reasoning about code, and will result in an ecosystem of overall higher quality.<br><br>Sent from my iPad</div><div><br>On Jul 5, 2016, at 6:49 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I'll bite.<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 5, 2016 at 4:11 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* What is your evaluation of the proposal?<br></blockquote><div><br></div><div>Strong +1. I like this proposal because it forces programmers vending a public API to think about their extension points, and it also provides guarantees to consumers of library and framework APIs as to whether the framework developer intended for a particular class or member to serve as an extension point. More controversially, I like it because it trades off short-term subclass-based hacks in favor of a library ecosystem years down the line that will be significantly higher in quality than it would otherwise be - both because it'll be harder to write misbehaving code, and because it'll support an emerging culture in which API design merits more careful consideration than it would otherwise get.</div><div><br></div><div>I am largely unmoved by arguments involving Cocoa or misdesigned libraries: Apple framework engineers will annotate their frameworks however they want no matter what default we choose; the possibility of badly written code would argue against things like access control, static typing, 'noescape' by default, the lack of swizzling, or any of a huge number of features that could conceivably be used to patch misbehaving code. Developers working in the Apple ecosystem can always fall back to Objective-C as an escape hatch if they really need to monkey-patch Apple framework classes.</div><div><br></div><div>I have a question: one of the alternative syntaxes ("public(subclassable)") is listed as a potential candidate for expansion when resilience is implemented. Is there a description of a potential resilience syntax for the primary proposal?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Is the problem being addressed significant enough to warrant a change to Swift?<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Does this proposal fit well with the feel and direction of Swift?<br></blockquote><div><br></div><div>Most definitely. For example, making closures non-escaping by default fits into the same model: expose only the most limited guarantees by default, with easy discoverability of more powerful guarantees should a framework author wish to use them. Another example is the raw pointer API proposal currently in the works. In this context, "limited" is not a liability, it is an asset: the more narrow the default semantics are, the easier it is for users to reason about the correctness of their code, and the more aggressively the compiler can optimize.</div><div><br></div><div>Indirectly, this proposal may also encourage framework authors to more carefully consider whether classes or protocols are better suited as extension points for their particular applications. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br></blockquote><div><br></div><div>n/a</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br></blockquote><div><br></div><div>I read through the proposal carefully, and have read/participated in most of the threads on the topic over the past few months.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
More information about the Swift evolution process is available at<br>
<br>
<a href="https://github.com/apple/swift-evolution/blob/master/process.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/process.md</a><br>
<br>
Thank you,<br>
<br>
-Chris Lattner<br>
Review Manager<br>
<br>
_______________________________________________<br>
swift-evolution-announce mailing list<br>
<a href="mailto:swift-evolution-announce@swift.org">swift-evolution-announce@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution-announce" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution-announce</a><br>
</blockquote></div><br></div></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>