[swift-evolution] [swift-evolution-announce] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly

[Xiaodi Wu]

On Sat, Jul 16, 2016 at 1:16 PM, John McCall via swift-evolution <
swift-evolution at swift.org> wrote:

> On Jul 16, 2016, at 11:03 AM, T.J. Usiyan <griotspeak at gmail.com> wrote:
>
> "open is invalid on declarations that are not also public (see the
> Alternatives discussion for rationale)."
> +
>
> "If an open class inherits an open method from a superclass, that method
> remains open. If it overrides an open method from a superclass, the
> override is implicitly open if it is not final."
>
> I understand that the intent is probably not to say that subclasses are
> public by default. My point is that those two statements, without an
> explicit spelling out of the implicit access level, could lead me to
> believe that subclasses are implicitly public by default. It is open to
> interpretation. Neither the prose nor the code examples address it.
>
>
> I see your general point.  I'll think about how to re-word this; it may be
> sufficient to just remove the requirement that open methods appear in open
> classes.  Suffice it for me to say now, officially, that this proposal does
> not require classes to be public or open just because they override open
> methods from an open superclass.
>

It might be barely sufficient solely to remove the requirement that open
methods appear in open classes. However, if my subclass is internal, I
shouldn't be required to declare a `public override` of an open method just
to satisfy the rules for `open`, which would be forced by the rule that
`open` is invalid on declarations that are not also `public` combined with
the rule that overrides of an open method are by default open.

This would degrade the developer experience significantly, since a
beginning developer writing only internal subclasses for their own app
would now be required to litter either `public override` or `final
override` throughout their code in the ordinary course of subclassing. On
reconsideration, it might be best if overrides are not implicitly open.


> John.
>
>
>
> On Sat, Jul 16, 2016 at 1:35 PM, John McCall <rjmccall at apple.com> wrote:
>
>> 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> 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> wrote:
>>
>>>
>>> > On 16 Jul 2016, at 16:10, T.J. Usiyan via swift-evolution <
>>> 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/a7fe17a4/attachment.html>