> 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`.
-David
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
