<div dir="ltr">On Wed, Jun 15, 2016 at 1:37 PM, Robert Widmann via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The scope of the *declaration* is not the issue.  The scope of its *members* is.<br></blockquote><div><br></div><div>Oy, if we&#39;re to have both `fileprivate` and `private`, then the previously visually appealing rule about maximum visibility of members will have to be a little messy.</div><div><br></div><div>IIUC, the problem is this: the current rule is that an internal type can have members that are at most internally visible (not public), and that a private type can have members that are at most privately visible. This is nice and tidy because in all cases, the declaration and the members it encloses are always in the same module and in the same file. But, with the new meaning of `private`, the top-level declaration is actually in a *different* scope than its members. So, a private type must be allowed to have members that are at most fileprivately visible.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
~Robert Widmann<br>
<br>
2016/06/15 11:36、Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>&gt; のメッセージ:<br>
<div class="HOEnZb"><div class="h5"><br>
&gt; 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>
&gt;<br>
&gt; -Matthew<br>
&gt;<br>
&gt;&gt; On Jun 15, 2016, at 1:31 PM, Robert Widmann via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; 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>
&gt;&gt;<br>
&gt;&gt; Thoughts?<br>
&gt;&gt;<br>
&gt;&gt; ~Robert Widmann<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; swift-evolution mailing list<br>
&gt;&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>