<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>