Trying to follow the discussion in this thread, but can't understand what
is the main problem with SE-0025 proposal? Could someone describe briefly ?
I believe this will help also for others who missed the main point to join
the discussion.
As I understand the proposal link is:
https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md
I also find `fileprivate` keyword odd/ugly and think we need better name.
Was 'local' mentioned as alternative?
After reading the proposal, I have a question: do we need to allow
`private` access modifier for top-level type? I.e. it seems like any
top-level type of function can be only `public`, `internal`(default) or
`fileprivate`. It seems for me that `private` for top-lever type just has
no sense given the new definition of `private` : "Properties, functions,
and nested types marked this way would be completely hidden outside the
class or class extension definition."
Sorry if I missed something important and all of this was already discussed.
On 29.06.2016 20:53, Jordan Rose via swift-evolution wrote:
On Jun 29, 2016, at 10:51, Michael Peternell
<michael.petern...@gmx.at> wrote:
Hi,
Maybe I'm wrong but as I understood the semantics of the visibility
modifiers as this: 1) each declaration X has a certain scope S 2)
sub-declarations of X have the same scope S unless the scope is
explicitly stated with a keyword (but rule #8 (about `public` access)
is stronger.) 3) a sub-declaration can explicitly state its scope, but
only if this wouldn't result in it having a larger scope than its
parent-declaration. 4) it follows: if X is `internal`,
sub-declarations of X are `internal` too. (without proof) 5) it
follows that: if X is `fileprivate`, sub-declarations are
`fileprivate` too. (without proof) 6) it DOES NOT follow that: if X is
`private`, sub-declarations of X are `private` too. (no proof, but
code examples below)
// ***
// Example: ACME/Happy.swift (should compile) private class C { var
foo: Int = 0 }
// C is visible here. // C.foo has the same scope as C, so it is
visible here too.
func jaa() { let c = C() c.foo = 4 }
// ***
// Example: ACME/Coyote.swift (should compile too) private class F {
fileprivate func haa() { print("haa.") } }
// F is visible here. // F.haa is visible here because F.haa is
fileprivate. // Since Scope(F) == Scope(F.haa) and therefore Scope(F)
>= Scope(F.haa), this is valid. // (with ">" I mean "is strict
superset of", ">=" means "is superset of or equal to") // (But I do
admit that it looks ugly.)
func ha() { let f = F() f.haa()
// This is okay too. jaa is internal jaa() }
// ***
// Example: ACME/Shy.swift (does not compile) private class S {
private func sayHello() { print("Hello?") } // sayHello() is visible
here // C and F are NOT visible here // ha and jaa are visible here }
// S is visible here // S.sayHello is not visible here // The Scope(S)
> Scope(S.sayHello) even though both are private // (with ">" I mean
"is strict superset of")
func noo() { let s = S() // this works s.sayHello() // compile error.
sayHello() not visible here }
// ***
Isn't this what `fileprivate` should mean?
For `public`, we add the following set of rules we applied the above
rules (which should have higher priority than the rules above): 7) A
top level declaration is implicitly internal unless specified
otherwise. 8) A sub-declaration of a declaration with public scope is
implicitly internal unless specified otherwise.
These might be the rules you want, but they are not the rules in the
compiler and they are not mentioned in SE-0025. Again, we weren’t happy
with the idea of a “parent" access level that you can’t spell but that
still has to show up in diagnostics. If that’s the direction we want to
go in, we probably need a full review.
Jordan
_______________________________________________ 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
