<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Jun 15, 2016, at 8:48 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Perhaps the proposal can be amended with this information with the approval of the core team. I imagine that a list of rules and a chart might be valuable. Even if adding to the proposal is the wrong way to go, a publicly accessible and vetted document would be useful to refer people to. Maybe someone can step up and form a working group.</div></div></blockquote><div><br></div>I'm sure the core team will chime in when they have a chance (but probably not during WWDC). If Ilya doesn't reply and nobody else wants to do it I would be happy to clarify this in an update to the proposal after we hear from the core team.<div><br></div><div><br><blockquote type="cite"><div><div class=""><br class=""></div><div class="">-- E</div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 15, 2016, at 5:51 PM, Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I think you guys are making this more complicated than it is. The rules here seem fairly simple:</div><div class=""><br class=""></div><div class="">1. The default access level is “internal”.</div><div class=""><br class=""></div><div class="">2. A type declared “private” at the top level will be visible to the file only.</div><div class=""><br class=""></div><div class="">3. If they are not given an access level, properties declared on the type will get the default “internal” access level, but since their containing type is not visible outside the file, they will not be visible either.</div><div class=""><br class=""></div><div class="">Thus any properties on the type will effectively inherit the access level of that type, unless the type’s access level is broader than “internal”. For the example of a private type at the top level of a file, its properties will effectively be fileprivate.</div><div class=""><br class=""></div><div class="">Charles</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 15, 2016, at 5:48 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On Jun 15, 2016, at 5:17 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class="">I await their opinions, but even with that change we still have a problem with the philosophy here. The motivation behind the fileprivate/private distinction is, as you say in the proposal "[a] reliable way to hide implementation details...". Why would you want any members you're trying to hide to be visible in any scope other than the one you create with the decl (which is, without a doubt, also a lexical scope)? It is analogous with other access control levels: a public outer decl implies public inner members just as a fileprivate one implies fileprivate inner members. Is it not antithetical to being able to hide things if they remain visible despite the outer decl declaring itself supposedly being sealed? In your examples, you declare private members that you do not wish to leak into top level scope because they are, after all, supposedly hidden. Should the same semantics you have given not also apply to private decls no matter where they lie? </div><div class=""><br class=""></div></blockquote><div class=""><br class=""></div><div class="">Sorry, missed the example in my last reply.</div><br class=""><blockquote type="cite" class=""><div class="">Should this compile:</div><div class=""><br class=""></div><div class="">private struct Outer {</div><div class=""> let inner = Inner()</div><div class="">}</div><div class=""><br class=""></div><div class="">Outer().inner</div></blockquote><div class=""><br class=""></div><div class="">Aside from the fact that you can't write a standalone statement at the top level of a file and it isn't clear what 'Inner' is, yes. This would be valid:</div><div class=""><br class=""></div><div class=""><div class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">private struct Outer {</span></font></div><div class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""> struct Inner {}</span></font></div><div class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""> let inner = Inner()</span></font></div><div class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">}</span></font></div><div class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></font></div><div class=""><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">private let inner = Outer().inner</span></font></div></div><div class=""><br class=""></div><div class="">Note that the top level 'inner' must be 'private' or 'fileprivate' because 'Inner' is not visible outside the file.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""></div><div class="">If this shouldn't:</div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">struct Outer {</span></div><div class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""> private let inner = Inner()</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">}</span></div></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">extension Outer {</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""> var inner2 : Inner { return self.inner }</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">}</span></div></div></blockquote><div class=""><br class=""></div><div class="">The extension introduces a new scope so this is not valid.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""></div><div class="">Visibility being a function of scope, lexical or otherwise, seems too coarse a metric for access control in general without further clarification of what the definition of "hidden" is.</div></blockquote><div class=""><br class=""></div><div class="">The lexical scope of the declaration itself (not a scope introduced by the declaration) is perfectly clear. You may not like it or agree that it is desirable but it certainly isn't ambiguous.</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""></div><div class=""><div class="">~Robert Widmann</div></div><div class=""><br class="">2016/06/15 12:38、Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 15, 2016, at 2:29 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">The meaning of private according to the proposal is not scope-dependent, it is decl-dependent. The mental gymnastics we are both going through right now are not in the proposal. I would like them to be.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I agree that the proposal is too sparse on the details and that is the source of the confusion. </div><div class=""><br class=""></div><div class=""><div class="">Ilya wanted me to write this proposal and only did it himself because I didn’t have time to do it as quickly as he wanted. I know what the original intent of the proposal was (I can’t speak for the core team on their mental model of it when they accepted it).</div></div><div class=""><br class=""></div><div class="">That said, the title of the proposal is “scoped access level” and the detailed design says "visible only within that lexical scope”. And the entire discussion was always about lexical scope. I believe the reason the “proposed solution” section says “current declaration” is because *most* lexical scopes are introduced by a declaration. That is sloppy language that should have been cleaned up prior to review.</div><div class=""><br class=""></div><div class="">I appreciate you working on implementing this. I also understand if you want to hold off until the core team can chime in on the semantics they intend. </div><div class=""><br class=""></div><div class="">Matthew</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">~Robert Widmann</div><div class=""><br class="">2016/06/15 12:26、Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 15, 2016, at 2:19 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">We have diagnostics specifically to prohibit this case. You cannot raise the access level of members.</div><div class=""><br class=""></div><div class="">private struct Foo {</div><div class=""> internal var x : String = ""</div><div class="">}</div><div class=""><br class=""></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">warning: declaring an internal var for a private struct.</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">Hence, the highest allowable level of access for x is private and it becomes invisible.</span></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">I would not like the compiler to synthesize this in my code, and if it did I would like the proposal to say it will raise access levels of members as you would like it to.</div></div></div></blockquote><div class=""><br class=""></div><div class="">That diagnostic is a good thing. I am not suggesting that you to disregard it.</div><div class=""><br class=""></div><div class="">What you are missing is that the meaning of `private` is scope-dependent. The following example is perfectly valid:</div><div class=""><br class=""></div><div class="">private struct Foo {<br class=""> fileprivate var x : String = “”<br class=""></div><div class="">}</div><div class=""><br class=""></div><div class="">`fileprivate` inside `Foo` specifies the same visibility as `private` at the top level, thus we are not “raising" the visibility of the member. If no modifier is provided for `x` it receives the same visibility as its containing type (up to `internal`).</div><div class=""><br class=""></div><div class="">Consider another example:</div><div class=""><br class=""></div><div class="">struct Foo {</div><div class=""> private struct Bar {</div><div class=""> var x : String = “”</div><div class=""> }</div><div class="">}</div><div class=""><br class=""></div><div class="">In this example we *cannot* mark `x` as `fileprivate` because that *would* raise the visibility of `x` beyond that of `Bar`. `Bar` is only visible inside `Foo`, not at file scope. This means that `x` also has visibility throughout the lexical scope of `Foo`, but not outside of it.</div><div class=""><br class=""></div><div class="">-Matthew</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><br class=""><div class="">~Robert Widmann</div></div><div class=""><br class="">2016/06/15 12:14、Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 15, 2016, at 2:04 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">2016/06/15 11:47、Matthew Johnson <</span><a href="mailto:matthew@anandabits.com" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">matthew@anandabits.com</a><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">> のメッセージ:</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class="">On Jun 15, 2016, at 1:37 PM, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:<br class=""><br class="">The scope of the *declaration* is not the issue. The scope of its *members* is.<br class=""></blockquote><br class="">Let’s consider an example:<br class=""><br class="">private struct Foo {<br class=""> var bar: Int<br class="">}<br class=""><br class="">// elsewhere in the same file:<br class="">var foo = Foo(bar: 42)<br class="">foo.bar = 44<br class=""><br class="">`Foo` is declared private. Private for this declaration is at the file scope. The `bar` member has no access modifier so it has the same visibility as the struct itself, which is file scope. This will also be true of the implicitly synthesized memberwise initializer. <br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">No, it is also private. It does not inherit its parent scope because, following the letter of the proposal, that symbol will only be visible within the current declaration. We cannot arbitrarily break access control rules because it is convenient in one special case.<span class="Apple-converted-space"> </span></span></div></blockquote><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">This means that it is possible to initialize `foo` with a newly constructed instance of `Foo` and to modify the `bar` member anywhere else in the same file.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">bar is not visible here. If it were you could break access control rules.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">If `bar` was also declared `private` this would not be possible as its visibility would be restricted to the surrounding scope of the initial declaration of `Foo`. This means `Foo` would need to provide an explicit initializer or factory method with `fileprivate` visibility in order to be usable.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">bar is private. Declarations within Foo cannot decide to raise that access level to make themselves more visible. If this should be the case, the proposal must be amended as much.</span></div></blockquote><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">Members with no explicit access modifier should have the same *visibility* as their containing type (with a maximum implicit visibility of internal), not the same *modifier* as their containing type. The only case where there is a distinction is the new `private` visibility. Maybe that is what is causing the confusion?<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">That is not what the proposal says. The proposal says it is invisible outside the current decl, which is the containing structure here.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div class=""><br class=""></div><div class="">The access modifier is applied to `Foo`, not `bar`. `Foo` is visible in the scope of the “current declaration” (this is badly worded - it should say current scope, which is the file). Because `Foo` has a visibility lower than `internal` the default visibility of its members match the visibility of `Foo`, which again is the current scope: the file. The detailed design section of the proposal is sparse, but it correctly uses the phrase "visible only within that lexical scope” rather than the less precise (in the case of top-level code) “current declaration”.</div><div class=""><br class=""></div><div class="">I didn’t write the proposal but I was very heavily involved in the discussions and IIRC I provided the original suggestion for introducing a scoped access modifier.</div><div class=""><br class=""></div><div class="">If my example was the following:</div><div class=""><br class=""></div><div class="">private struct Foo {<br class=""> private var bar: Int<br class="">}</div><div class=""><br class=""></div><div class="">Then what you are saying would be correct. However, The example I showed did not provide an access modifier for `bar`.</div><div class=""><br class=""></div><div class="">You cannot just apply the same *access modifier* to members of the type that do not contain an access modifier. You have to apply the same *visibility* (limited to internal). When a type is marked as `private` in the lexical scope of the file, its unmodified members will be visible in the same lexical scope as the type itself (which is the file in the current example).</div><div class=""><br class=""></div><div class="">-Matthew</div><br class=""><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">Does this help?<br class=""><br class="">-Matthew<br class=""><br class=""><blockquote type="cite" class=""><br class="">~Robert Widmann<br class=""><br class="">2016/06/15 11:36、Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> のメッセージ:<br class=""><br class=""><blockquote type="cite" class="">The scope for a top-level declaration is the file itself. This means that top-level declarations with `private` and `fileprivate` should have the same behavior. They should not be uninstantiable or unusable.<br class=""><br class="">-Matthew<br class=""><br class=""><blockquote type="cite" class="">On Jun 15, 2016, at 1:31 PM, Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">While implementing SE-0025 (fileprivate), I noticed an interesting bug in the proposal. Under the implementation outlined there, any top-level structure, class, or enum declared private cannot possibly be instantiated and so cannot be used in any way. Because of this, private top-level declarations are more often than not blown away entirely by the compiler for being unused. It seems strange to me to allow a key language feature to act solely as a hint to the optimizer to reduce the size of your binary. Perhaps the restrictions around private needs to be relaxed or the line between fileprivate and private needs to be investigated again by the community before inclusion in the language.<br class=""><br class="">Thoughts?<br class=""><br class="">~Robert Widmann<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></blockquote></blockquote></blockquote></blockquote></div></blockquote></div><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></blockquote></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>