<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 Mar 29, 2016, at 12:18 PM, Jordan Rose 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=us-ascii"><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 29, 2016, at 10:14 , David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Additionally, we think we can get away with renaming "private" because most current uses of "private" (file-scoped) declarations are within the same (brace-bound) scope anyway;</div></div></blockquote><br class=""></div><div class="">A quick look through my code bases verifies that this is true with my small sample of code. The only outliers are private members on types accessed by extensions, but those are fairly rare in my use cases, and arguably, those should be changed to internal. Maybe that varies for others.</div><div class=""><br class=""></div><div class="">Honestly, if the assertion is already that most of the current private use cases are for lexically scoped uses anyway, is it really worth trying to add a file-based private as well that essentially pops out of the lexical scope only up to the file level? For those use cases, just use `internal`. Using `private` would still be available for top-level declarations on the file.</div><div class=""><br class=""></div><div class="">We would end up with just this:</div><div class=""><br class=""></div><div class=""><div class=""><ul class="MailOutline"><li class="">`public` - publicly exported for use by all code that uses the library</li><li class="">`internal` - only allowed for use within the current module</li><li class="">`private` - the new, lexically scoped modifier</li></ul><div class=""><br class=""></div></div></div><div class="">If file-based is really required for a small set of cases, use `private internal`.</div></div></div></blockquote><br class=""></div><div>A good handful of people already enumerated several cases where file-based scoping is useful, and I very much agree. Leaking helper operations across an entire module just because they can't be lexically scoped, or don't make sense to, doesn't seem like a good answer to me.</div></div></blockquote><div><br></div>+1<div><br><blockquote type="cite"><div><div><br class=""></div><div>Jordan</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>