[swift-evolution] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

[Leonardo Pessoa]

Then we would need another keyword to close the method again should we
need/want.

   public sealed override func foo()

I don't see any association between override and open/sealed as they
relate to two different aspects of class inheritance. One declares the
method is overriding a superclass method; the other that this method
can(not) be further overriden. With inherited openness, it should be
possible to revert it and defaulting to inherited openness will demand
the introduction of another keword (sealed/closed/nonopen).

It would be simpler to have one global default and one keyword only.
Two keywords add to complexity to learn the language.

L

On 18 July 2016 at 14:12, John McCall via swift-evolution
<swift-evolution at swift.org> wrote:
>> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution <swift-evolution at swift.org> wrote:
>> I disagree that an `open` method overridden from a superclass is implicitly `open`.
>>
>> As the rationale for the proposal states, overridability is hard to get right, and there is no guarantee that the consumer of an API is going to think about it. The default for override methods should not be `open` or `final`, it should be the internal equivalent.
>>
>> A coder subclassing a public API, who themselves wants their subclass to be subclassable, should need to restate `open` where appropriate.
>
> I don't think that defaulting to non-open would be a good idea.  Like I covered in the proposal, inherited open methods remain open; letting an override implicitly close off an open method would create a pretty unfortunate error-of-omission situation.
>
> We could remove the default here and require the method to be explicitly open/nonopen/final, but then we really do pile up the modifiers:
>
>   public open override func foo()
>
> To me, the fact that it's already marked with "override" suggests the possibility of open-ness enough to remove the need to re-state it.  I can see why you might disagree, though.
>
> John.
>
>>
>> This also seems to be a general conflict in that you can always reduce the access, e.g. an API might have a `public open` method, but the subclass should be able to declare that as `override private` and thus the `open` keyword would be invalid in this context.
>>
>>
>> Scott
>> _______________________________________________
>> 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