I'll bite.
On Tue, Jul 5, 2016 at 4:11 PM, Chris Lattner <clatt...@apple.com> wrote:
>
>
> * What is your evaluation of the proposal?
>
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.
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.
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?
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
>
Yes.
> * Does this proposal fit well with the feel and direction of Swift?
>
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.
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.
> * If you have used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
>
n/a
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
I read through the proposal carefully, and have read/participated in most
of the threads on the topic over the past few months.
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris Lattner
> Review Manager
>
> _______________________________________________
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
