[swift-evolution] Replace Fileprivate with Hidden + Import Hidden

[Rien]

-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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution