Introduce type-private access level

Evolution Pitches
55

Here's something that I saved for myself as a gist long time ago.

Having all these new access modifier keywords adds so much cognitive load. Why can't we simplify things by only having private, internal, public and open access modifiers?

Anything else would be achieved through access modifier limiters in a hypothetical form of a suffix (or a prefix).

Current New
private private(file)
- private
fileprivate internal(file)
internal internal
public public
open open
  1. Current private would be re-branded as private(file) or private with (file) limiter.
  2. The new private will be type-private by default and does not require an explicit type limiter, like current internal and higher access modifiers already do today.
  3. Current fileprivate would be rebranded as internal(file) which clearly describes the visibility of the modifier that it has today.
  4. [Debatable]: Top-level usage of private or a limited private(file) could be banned in favor of internal(file), or at least non limited private has to be banned.
  5. Last but not least, we could also try and see if closed protocols can be patched in shift as well.
    • public protocol would disallow the user of the framework to conform to the protocol, similar to how public class disallows inheritance.
    • open protocol would act like current public protocol and allow conformances again.
      This would allow library vendors to expose some implementation detail protocols to the public without worrying that the library user would conform some types to it, hence these will be closed to the library.

A phased migration can be purely mechanical.

  • Phase 1: Rename private to private(file), fileprivate to internal(file), public protocol to open protocol and disallow pure private access modifier as well as public protocol in that transition (or warn about the upcoming changes)
  • Phase 2: Introduce new private and public protocol.
1 Like