IMO there is no need for something like typepublic to even exist, but in theory 
it would be something like where a subclass has more visibility of the internal 
stuff of its super type. I’m just saying that someone will want this, because 
that person might thing that typepublic and typeprivate would be consistent.

In general I’m for anything that adds flexibility, but flexibility means also 
more complexity.

The thing is, typeprivate cannot replace fileprivate, just because fileprivate 
adds internal visibility to other scopes inside the same file and does not 
restrict it to the same type. And I really love that aspect of Swift. :)

It already has been discussed thousands of times but I cannot resist and also 
state my preference to something like:

private       // like `private(scope)`
private(file) // like `internal(file)`
private(type) // in your case
This is a POP language right? So lets focus on fixing and improving protocols. 
:) We should start with open/public protocol.

PS: I also cannot wait for existentials to drop typealias ProtoB = Any<Proto> 
where Proto.A == B where B comes from a generic parameter list and A is an 
associated type.



-- 
Adrian Zubarev
Sent with Airmail

Am 2. Dezember 2016 um 12:36:45, Gonçalo Alvarez Peixoto 
([email protected]) schrieb:

Also, would you be so kind to provide an example where typepublic would be 
useful? Maybe you're thinking of allowing member access to subclasses? Would 
that fall into a possible "protected" realm?
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to