To put it more forcefully, I believe that ‘fileprivate’ currently suffers from 
the same problem that singletons do.  That is, the main reason to make 
something ‘fileprivate’ instead of ‘private’ is to allow some sort of 
extension.  It is highly unlikely that the point you were required to expose 
for that extension will not also be needed by other extensions.  Both 
‘internal’ and submodules would extend the boundaries of the problem from the 
file boundary to the module/submodule boundary… but the underlying problem 
still persists.

If it is the module designer’s intent to limit extension, then fine, but it 
also often forces a design to be much more brittle and fragile than it needs to 
be.  One of two things happens: extension becomes impossible or there is access 
inflation, giving inappropriate levels of access (usually combined with a note 
in the documentation saying not to use it).

Thanks,
Jon


> On Oct 16, 2016, at 3:28 PM, T.J. Usiyan <griotsp...@gmail.com> wrote:
> 
> I don't like this at all and it comes down to  "what is hidden can also be 
> unhidden". This, to me, feels like it would create more confusion than it 
> would address. Why not just use `internal` for `hidden` items?  If we're ok 
> with modifying import statements, why not simply have a command that imports 
> `fileprivate` stuff? (not advocating for this).
> 
> I think that submodules would have really helped with this issue and it is 
> unfortunate that we couldn't get them in for swift 3. 
> 
> On Sun, Oct 16, 2016 at 4:34 PM, Jonathan Hull via swift-evolution 
> <swift-evolution@swift.org <mailto: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 <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <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