[swift-evolution] [Discussion] A Problem With SE-0025?

[Vladimir.S]

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