-1.

If an API designer wants to allow access to a “hidden’ member, he should be in 
control of that access.
The proposed chance simply opens up access completely and leads to API 
vulnerability.

(I am in favour of a “friend” solution, in which the API designer explicitly 
allows access to identified members of the API users.)

Rien.


> On 16 Oct 2016, at 22:34, Jonathan Hull via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> I keep wanting a “protected” access level, but I must also admit that there 
> was something really elegant about Swift 2’s access scheme (and I think most 
> of us feel like the word ‘fileprivate’ feels out of place).  I was thinking 
> about how to mesh those two ideas, and I think I may have come up with a 
> solution.
> 
> I propose we replace ‘fileprivate’ with a new ‘hidden’ access level.  Hidden 
> would work exactly the same way as fileprivate does now, but adds the 
> connotation that what is hidden can also be unhidden.  By adding ‘import 
> hidden TypeName’ to another file, that file also gains access to all of the 
> hidden items of that type (kind of like if it was in the same file).
> 
> #FileA        
>       import Foundation
> 
>       Struct A {
>               private var x:Int
>               hidden var y:Int  //This is just like fileprivate, but can also 
> be shared with other files
>       }
> 
>       extension A {
>               //y can be accessed here because they are in the same file
>       }
> 
>       
> #FileB
>       import Foundation
>       import hidden A  //This allows the entire file to see A’s hidden 
> variables
> 
>       extension A {
>               //y can be accessed here because of the ‘import hidden’ 
> declaration
>       }
> 
> 
> #FileC
>       import Foundation
> 
>       extension A {
>               //y can NOT be seen or accessed here because it is hidden
>       }
> 
> 
> I think this is a fairly elegant solution to our protected dilemma, which 
> also feels in sync with Swift 2’s file-based scheme.  The key features:
>       • Extensions no longer need to be piled in the same file if it is 
> getting too long
>       • Subclasses can be in their own file, but still have access to the 
> necessary parts of their superclass
>       • It communicates the author’s intent that the items are not meant to 
> be visible to its users, but that it is expected to be used for 
> extension/subclassing
>       • It requires an explicit statement ‘import hidden’ to access the 
> hidden variables. Safe by default, with override.
>       • It is not bound by module boundaries  (i.e. you could use it for 
> subclassing classes from an imported module)
>       • Roughly the same length as ‘private’ and ‘public’ so various 
> declarations packed together are much easier to read (fileprivate breaks 
> reading rhythm)  
> 
> Worth a formal proposal?
> 
> Thanks,
> Jon
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to