> On Jul 18, 2016, at 10:59 AM, Scott James Remnant <[email protected]> wrote:
>> On Jul 18, 2016, at 10:12 AM, John McCall <[email protected]> wrote:
>>
>>> On Jul 17, 2016, at 3:12 PM, Scott James Remnant via swift-evolution
>>> <[email protected]> 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.
>>
>
> I think that this explicitness is more Swifty.
>
> First consider why `open` is a bad inherited default:
>
> public class Superclass {
> public func foo() { }
> }
>
> class Subclass : Superclass {
> override func foo() { }
> }
>
> Subclass is `internal` not `public`, likewise Subclass.foo is `internal` and
> not `public`. If the default was that these became `open`, the default would
> be compiler errors at every definition (and compiler errors for everything
> that was defined in the superclass that you haven’t overridden) because
> Subclass cannot be `open` and `internal`, and Subclass.foo cannot be `open`
> and `internal`.
This was covered in a different sub-thread, but this is not a real thing. The
restriction against writing "open" on a non-public declaration was only ever
intended to apply to explicit "open"; also, as Xiaodi Wu pointed out, it is
inconsistent with the resolution of SE-0025 and should be removed.
> And requiring that your derivation from a public API be also public seems
> exactly opposite to the intent of “apply thought before making things
> public,” and very much against “apply even more thought before making public
> things open."
>
>
> To make anything public, even a subclass, you have to be explicit in Swift
> already not just at the class level:
>
> public class Superclass {
> public func foo() { }
> }
>
> public class Subclass : Superclass {
> override func foo() { } // Error: Overriding instance method must be
> accessible as the declaration it overrides.
> }
>
> But the function level too:
>
> public class Superclass {
> public func foo() { }
> }
>
> public class Subclass : Superclass {
> override public func foo() { }
> }
>
>
> So I really don’t agree that `open` suggests anything, in fact I think
> consistently in Swift restating things is the norm.
Perhaps.
John.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
