> private(scope) decl 
> 
> Where scope is optional and defaults to full private. Can take "file" and 
> "type" values. I.e:
> 
> private (file) var i = 1
> private func a()
> private (type) func b()
> 
> This way we can have a very fine grained access levels and maintain a better 
> structure. Who knows maybe in Swift 5 there will be need for more.
There might be submodules someday, which could be incorporated as well:
private(submodule)
or even
private(module: "MyLib", file: "Helpers.swift", type: Foo)
for a declaration that can be accessed from several locations.

We could even go further with
overridable(module) callable(subclass) func foo()

The question for me is how much complexity should be accepted as a tradeoff for 
increased expressiveness?
"private, internal, public" was quite simple, but the current system is already 
quite complicated, and it doesn't scale well.

The whole topic has come up several times, and I keep referring to file access 
rights in Unix… so afaics, we are basically talking about ACLs for source.

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

Reply via email to