Sent from my iPad
> On Jul 6, 2016, at 12:24 AM, Charlie Monroe via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Huge +1.
>
> Question about inheritance though:
>
> class A {} // Not publicly subclassable
> subclassable class B: A {} // Publicly subclassable
> class C: B {} // Not publicly subclassable? Or is the subclassability
> inherited?
This is a great question. There are really two questions:
Can B be marked "subclassable" even though its superclass isn't? Allowing this
allows creation of new classes with A as an ancestor. Since this is explicitly
opt-in all within the same module I'm inclined to say we should allow it.
Is subclassability inherited by in-module subclasses? This seems to me opposed
to the spirit of closed by default. I think it is better to require annotation
on *every* class an method that is open to extension outside the module,
regardless of what choice a superclass makes,
This gives module authors the most control over *exactly* which classes can be
used as superclasses outside the module (A and C don't need to be subclassable
just because B needs to be.
-Matthew
>
> I'm not a big fan of the subclassable keyword either since it's quite long,
> not to mention it contains "class" which is the next keyword, making it
> visually repetitive.
>
> I'd prefer open on both class and func to introduce only one keyword instead
> of two and possibly make it as a modifier of public to keep it in line with
> private(set)...
>
>> On Jul 6, 2016, at 1:11 AM, Chris Lattner via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> Hello Swift community,
>>
>> The review of "SE-0117: Default classes to be non-subclassable publicly"
>> begins now and runs through July 11. The proposal is available here:
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
>>
>> Reviews are an important part of the Swift evolution process. All reviews
>> should be sent to the swift-evolution mailing list at
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> or, if you would like to keep your feedback private, directly to the review
>> manager.
>>
>> What goes into a review?
>>
>> The goal of the review process is to improve the proposal under review
>> through constructive criticism and contribute to the direction of Swift.
>> When writing your review, here are some questions you might want to answer
>> in your review:
>>
>> * What is your evaluation of the proposal?
>> * Is the problem being addressed significant enough to warrant a change
>> to Swift?
>> * Does this proposal fit well with the feel and direction of Swift?
>> * If you have used other languages or libraries with a similar feature,
>> how do you feel that this proposal compares to those?
>> * How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>>
>> 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 mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
