<div dir="ltr">Extensions can already do what partials would do, and more—Swift does not need two features that are almost the same but with subtle differences when it comes to the visibility of its members. That seems like something that will only cause confusion for users. Partials feel like trying to shoehorn a feature from another language into Swift to solve an unrelated problem.<div><br></div><div>Swift 2 and 3 have never had type-oriented visibility—they've only had visibility that covered contiguous regions of the symbol space ("the universe", "the module", "the file", and then in Swift 3, "the enclosing scope"). Being able to split a type's *scope* with partials (as opposed to just the type itself with extensions) across multiple files files would be quite inconsistent with how visibility in Swift has been so far.</div><div><br></div><div>At some point, we need to come to grips with the fact that there are going to be keywords we think are a little ugly (I much preferred the original definition of "private", but "fileprivate" is part of Swift now and I've moved on) and that there's never going to be a way to perfectly audit visibility of every single member that we write in a way that makes everyone happy.</div><div><br></div><div>I don't want to sound dismissive, but I feel like it's simply not productive to keep rehashing visibility over and over again.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Apr 10, 2017 at 7:20 AM Jose Cheyo Jimenez via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg"></div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg">On Apr 10, 2017, at 12:20 AM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 10 Apr 2017, at 08:21, Jean-Daniel <<a href="mailto:mailing@xenonium.com" class="gmail_msg" target="_blank">mailing@xenonium.com</a>> wrote:</div><br class="m_-533664844060846617Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">Le 10 avr. 2017 à 07:15, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> a écrit :</div><br class="m_-533664844060846617Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><br class="m_-533664844060846617Apple-interchange-newline gmail_msg"><br class="gmail_msg">On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-533664844060846617Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg">This struck me as a bit odd at first, but the more I think about it, the more I really like the ability to nest extensions/scopes. The one issue I see is sticking that public extension inside a private one. I think you would have to mark ‘secret: Int’ as private instead of the extension itself to allow the effect you are looking for...<div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">What I ultimately want is the ability to declare storage in extensions in the same submodule. Combining that with fileprivate will allow the same tricks without the indentation (together in their own file). This nesting will help in the mean-time (and would still be useful after for those who prefer to organize their code in fewer/longer files). I think it could be helpful in other ways too…</div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div>What do you think of `partial` types like C# but limited to a file?</div><div class="gmail_msg"><a href="https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx" class="gmail_msg" target="_blank">https://msdn.microsoft.com/en-us/library/wbx7zzdd.aspx</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html" class="gmail_msg" target="_blank">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035360.html</a></div><div class="gmail_msg"><br class="gmail_msg"></div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg"><br class="gmail_msg"></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="gmail_msg">That's the direction the new proposal (0169) is going towards with extensions in the same file.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div>I don’t see how SE-0169 do that more than any other meaning private got until now. This was already the case with the initial meaning of private, and was the case with fileprivate.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The current semantics of private don’t give any support for partial types like in C# because the accessibility is restricted to the current scope. With SE-0169’s private, extensions in the same file as the type share that scope. Plus, the <b class="gmail_msg">Alternatives Considered</b> section of the proposal discusses potential future directions where those extensions could look even more like C# partials :)</div></div></div></blockquote><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div></div><div dir="auto" class="gmail_msg"><div style="direction:inherit" class="gmail_msg">SE-169 could be emulated cleanly by introducing partial types within the <u class="gmail_msg">same scope</u> as a new feature completely separate from extensions. Partial types would not require redefining how private or extensions work now. It would also serve as a way to communicate to the user that the type is not done being defined so if they want to encapsulate the type completely, They have to make it non partial. </div></div><div dir="auto" class="gmail_msg"><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><div style="direction:inherit" class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">And for file splitting and visibility control, we need submodules. Until then, if this proposal is to define the ultimate meaning of private, I rather like this meaning that the SE-0025 one.</div><div class="gmail_msg"><br class="gmail_msg"></div></div></div></blockquote></div><br class="gmail_msg"></div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-evolution mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="gmail_msg"></div></blockquote></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>