On 04.04.2017 0:59, Brent Royal-Gordon wrote:
On Apr 3, 2017, at 2:54 PM, Vladimir.S via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
Moreover, I think that we need *additional* access level(to current
'private'), which will mean 'can be accessed from extensions and subtypes
in the same *module*' to be able to split type's conformances to number
of files and don't make implementation details accessible&visible for
whole module. (there was 'extensible' modifier discussed previously).
If we wanted to do this, I think we'd want a `protected` modifier that was
orthogonal to `internal` and `private` (which would probably revert to
`fileprivate` semantics):
I don't think so, IMO it seems like over-complicated structure of access
levels. I believe it is a required minimum to have current 'private' and
something similar scope(type)-based but with wider scope. (in addition to
public/internal/fileprivate). IMO this will resolve major percent of
problems raised in the thread.
struct Foo {
private let bar: Int// Only visible in this file
protected private let baz: Int// Only visible in this file and type
let quux: Int// Only visible in this module
protected let quuux: Int// Only visible in this module and type
}
We might then consider extending `protected` to `public` and `open` scope.
I mention this not because I think type-based scoping is a good idea, but
because if we're gonna do it, we shouldn't do it halfway.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
