> On Mar 29, 2016, at 10:14 , David Owens II <[email protected]> wrote: > >> 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; > > 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. > > 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. > > We would end up with just this: > > `public` - publicly exported for use by all code that uses the library > `internal` - only allowed for use within the current module > `private` - the new, lexically scoped modifier > > If file-based is really required for a small set of cases, use `private > internal`.
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. Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
