
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body 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 class=""><br class=""></div><div class="">-David</div></body></html>