[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly
John McCall
rjmccall at apple.com
Sat Jul 16 12:35:02 CDT 2016
> On Jul 16, 2016, at 9:32 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
> Sent from my iPhone
>
> On Jul 16, 2016, at 10:59 AM, T.J. Usiyan via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>> Yes, sorry, my point was that this consideration isn't spelled out.
>>
>> Another question is whether or not making a subclass of an open class public by default is what we want. I see why it would be, I just think that it is a wrinkle to default to internal otherwise but not here.
>
> I can't think of any good reason to assume a specific class should be public just because it is a subclass of an open class. The internal default would still be the right default in this case.
Right, there's no new restriction here. Of course you can make a private or internal subclass of a public open class — otherwise, you'd have to publicize every subclass of (say) UIViewController.
John.
>
>>
>> On Sat, Jul 16, 2016 at 10:32 AM, Karl <razielim at gmail.com <mailto:razielim at gmail.com>> wrote:
>>
>> > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> >
>> > What happens if I want an `internal` subclass of an `open` class?
>>
>> That should be allowable. You may want some optimised implementations, similar to how Apple used class-clusters in Obj-C. I don’t think that same pattern is exactly possible in Swift (I don’t think a class can set ‘self’ in its initialiser, or at least it couldn’t in Swift 1). But the same principle applies - you may want a public class which you don’t allow others to subclass, but you might have a static method or other function which returns an internal optimised implementation.
>>
>> If you used a protocol rather than a concrete type in that case, theoretically others could conform to it and throw their own objects back at your code, which goes against the point of this proposal.
>>
>> We might think about creating ‘sealed’ protocols, too.
>>
>> Karl
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160716/ffc8b170/attachment.html>
More information about the swift-evolution
mailing list