[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

[Vladimir.S]

On 22.07.2016 11:15, Dave Abrahams via swift-evolution wrote:
>>>....skipped...
>>
>> IMO, the safety of API contracts is secondary. This is about safety of
>> implementation - my code is possibly not "resilient" enough (to to
>> speak) to handle overriding arbitrary public members.
>
> I wrote that subclassability is not an important element of safety
> **independent of overriding**.  If you don't allow any overriding,
> your code is always “resilient” enough to handle subclassing.
>

I believe in this case the #2 approach, as formulated in proposal, just 
can't work - base class of public class can have(and can add) `open` 
methods/props, so for the author of such public class it is hard to know 
what other methods (other than explicitly marked by him/her as `open`) 
would be overridden.

So, seems like for #2 approach the proposal should be changed to not 
implicitly open inherited `open` methords/props. Author of public class in 
this case must explicitly mark as `open` each method/prop one wants to 
export opened.

Then, in this case, we have a problem with *inherited* methods/props that 
author *want* to open. In this case to remove boilerplate like 'public open 
func f() { super.f()}', I don't see another way than adding new concept of 
re-introducing of inherited method without its body :

public class B : A {
   public open *reintroduce* var property  // without type/details
   public open *reintroduce* func foo()  // without body

   public open override func bar()
   {
      //some code
      super.bar()
      //some code
   }

   public open func newFunc() {...}
   public func sealedFunc() {...}
}

(`reintroduce` as fast example of possible keyword for implementation of 
such feature)

Am I missing something?