Sent from my iPad
> On Mar 29, 2016, at 12:18 PM, Jordan Rose via swift-evolution > <[email protected]> wrote: > > >>> 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. +1 > > Jordan > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
