[swift-evolution] Swift evolution proposal: introduce typeprivate access control level

[Goffredo Marocchi]

I think Swift 4 is the last chance for something such as abstract methods and classes and we should really take another look at them soon. They are not a silver bullet, but still a very good tool to have in your tool belt.

Sent from my iPhone

> On 2 Dec 2016, at 15:36, Jeremy Pereira via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 2 Dec 2016, at 14:07, Benjamin Spratling via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I agree that there is a major problem with “subclasses must override these methods”.  We have no capability to describe this in Swift, and frankly, it feels like something that ought to be enforced.  It’s almost like we were really asked to conform to a protocol, but the protocol was a class.  Maybe this is an artifact from previous Obj-C development?  I.E. if it were designed in scratch in Swift it wouldn’t be a class with required overrides, but a protocol where every other method already had a default implementation?
> 
> In Java and C++ you would implement this with an abstract method. i.e. a method that has a declaration and no body. A proposal was made to introduce these but was deferred. Reading the rationale for the decision, it looks like the dev team were generally favourable but didn’t have time to do the implementation, plus there were some details that needed to be nailed down.
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md
> 
>> 
> 
>>> One of the simple examples would be: you need an API that requires overriding? Make it accessible for ancestors only (even in protocols). Despite the argument "ancestors can open it to public" (there are a lot of dangerous things to do) it makes the API much more clean and hides implementation complexity. Otherwise you just have to explain it in the doc "please don't call this method, it's an internal" which feels wrong.
>> _______________________________________________
>> 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