Access modifiers

[kyouko-taiga]

I'm opening the discussion about the design of Val's access modifiers. In my experience, access modifiers is a common topic of disagreement so I'm ready for very strong opinions ;)

Motivation

Access modifiers are an important component of API design. However, traditional approaches tend to be not very flexible and particularly not well-suited to extensions and post-hoc conformance declarations. Even Swift's design has some wrinkles.

Swift has 5 access modifiers (from least to most restrictive):

• open (only relevant to Swift's class system)
• public
• internal (default)
• fileprivate
• private

Despite these 5 modifiers, it is not possible to declare an extension that is able to access private members and expose new public entities. Since Swift uses extensions to declare post-hoc conformance, private details of a type must sometimes be exposed more than necessary just to support a conditional conformance declaration (unless the extension is in the same file).

Further, it is also not possible to allow a companion type to access private details of another type. Although this limitation can be mitigated using fileprivate and/or some clever nesting, it remains a hurdle in general.

Proposed approach

We define the following access modifiers:

• public
• internal
• scoped(to: S1, ..., Sn)
• private (default)

Note: internal is an alias for scoped(to: M) where M is the name of the enclosing module.

public means exposed outside of the enclosing scope. A public declaration is part of a module's API if and only if all its enclosing scopes are public. For example, in the file below, A and A.f are part of the module's API whereas A.g, B and B.f aren't.

public namespace A {
  public fun f() {}
  fun g() {}
}
namespace B {
  public fun f() {}
}

scoped(to: S1, ..., S2) can be used to expose a declaration nested in a scope without making it as visible as that scope. For example, in the file below, A.g is visible to the whole module but, unlike A.f, it is not part of that module's API.

public namespace A {
  public fun f() {}
  internal fun g() {}
}

scoped(to: S1, ..., S2) can also be used to confer access to a companion scope. For example, in the file below, A.f is only visible within A, B, and C.X.

public namespace A {
  scoped(to: B, C.X) fun f()
}
namespace B {}
namespace C {
  public namespace X {}
}

Note that a declaration that is scoped(to: S) is also visible in the extensions of S.

private means only visible within the enclosing scope and is the default access level. One exception is made for extension and conformance declarations in the same module, which are allowed to access the private members of the type they extend.

Note: This exception is more permissive than Swift, where it only applies to extensions in the same file.

private applied to top-level declarations of a file make them visible only to that file. Only public and internal top-level declarations are visible to the whole module.

Rationale

I originally thought we could get away with only one access modifier: public. A declaration would be private by default and public would simply make it visible to enclosing scope. If this scope is also public, then the nested declaration is also visible to its enclosing scope, etc. For example:

// `Foo` is visible in the containing file and isn't part of the module's API.
namespace Foo {
  // `Foo.f` is only visible in the containing file.
  public fun f() {}
  
  // `Foo.A` is only visible within `Foo`.
  type A {
    // `Foo.A.f` is only visible within `Foo`.
    public static fun f() {}
  }
}

// `Bar` is part of the module's API.
public namespace Bar {
  // `Bar.f` is visible part of the module's API.
  public fun f() {}

  // `Bar.g` is only visible within `Bar`.
  fun g() {}
}

This approach gets you surprisingly far, but it has a couple of annoying limitations. First, note that members of declarations that are part of a module API can't have members that are only visible within the module. Second, it is not possible to access private declarations in extensions.

For example:

public type A {
  // `A.f` is part of the module's public API.
  public fun f() {}
  // `A.g` is only visible within `A`.
  fun g() {}
}

extension A {
  fun h() {
    // `A.g` is not visible here.
  }
}

@dabrahams suggested a very nice feature that possibly addresses both issues.

if our access control ever turns out to be insufficient: we could add something like scoped(to: SomeScopeName)

This modifier is reminiscent of C++'s friend feature. I think that if we combine it with namespaces, then we can work around the two issues I mentioned.

Alternative considered

Rather than allowing all extension and conformance declarations access to the private declarations of the extended entity, we could add a protected modifier that confers and make private stricter. However, the benefits of this feature is questionable.

[Nobody1707]

I've been a long proponent of the idea that Swift changing the definition of private was a mistake. I am not convinced that anything more granular than public, internal (the default), and private (i.e. file private) are needed. Especially in a language with actual namespaces.

[kyouko-taiga]

It is not exactly clear to me what Swift "changed" about private. AFAICT, the way Swift's private works is pretty consistent with mainstream programming languages, at least at type scope. Besides, there isn't a canonical definition of what access modifiers are supposed to mean.

I strongly believe that choosing internal as a default was an odd choice in a language that otherwise consistently favors the most restrictive options. I'd like to avoid that in Val.

[Nobody1707]

When Swift first got access control in Swift 2, private meant the same thing as fileprivate does now. The renamed private to fileprivate when they added the current version.

[kyouko-taiga]

Thanks for the clarification. I would tend to agree with you then. I'd like to add that I do not feel very strongly about access modifiers in general (I was originally a Python developer if anyone can believe it) so I am all for keeping things simple.

[dabrahams]

1. I think the behavior of Swift's own access modifiers was updated at some point and that's the change the OP is referring to.
2. Choosing internal as a default is aimed at allowing people to use Swift without worrying about access control or paying for it syntactically (i.e. like Python). I'm not saying it is necessarily the best design, but I understand the choice. It's all about tradeoffs.

[kyouko-taiga]

Though I understand the goal, I'm not convinced using internal to avoid syntactic costs actually works. In Val sources, for example, most definitions need to be public. So we pay the syntax tax anyway. Maybe things work better for people who can fit all their code in a single module.

In any case, I think a better way to avoid the tax is something like @implicit <access-level>.

[kyouko-taiga]

After discussing with @dabrahams, we think we could start with only public, internal, and private. These modifiers would behave as described above with one additional exception: any extension or conformance defined in the same module would have access to private members of the extended type. For example:

// In A.val
public type A {
  var raw_value: Int
  public memberwise init
}

fun foo(a: A) -> Int {
  a.raw_value.copy() // error: `A.raw_value` is private
}

// In B.val
extension A {
  public fun bar() -> Int {
    raw_value.copy() // OK
  }
}

Assuming A.val and B.val are in the same module, A.bar would type check.