[Pre-Pitch] Import access control: a modest proposal

[beccadax (Becca Royal-Gordon)]

@jayton

By my reading of the pitch, this would be entirely a compile-time change and platform support would not be an issue. I may be misunderstanding though.

Correct—this change would be at compile-time. You’d need a newer compiler at your desk, but not a newer device in your users’ hands.

@ebg

Do we need special keywords here? Can the compiler inspect the API and automatically export those modules exposed publicly and keep those implementation-only which are not?

Probably, but I don’t think we’d actually want the compiler to infer public import any more than we’d want it to infer public class or public struct when you used a type in a public API. Your dependencies are an externally visible aspect of your module; explicitly controlling that aspect is a feature, not a bug.

@Philippe_Hausler

But there are times at which I want to control the scope of types such that they do not leak through implementations and a file private restriction would be welcomed in my book either spelled as fileprivate import or private import ether way feels like something that would be helpful for framework development (especially for those of us who need to work on things that do not expose internal bits to the outside world from our frameworks when it comes to layering or types).

Huh, that could actually be useful. I think it might be better as a separate proposal, though.

@AlexisQapa

in module Y :

import Profile
import struct X.Profile

let a = Profile.A() // doesn't work (I want to use the module Profile but swift select the type Profile)

I am very much thinking about solutions to this problem, but it’s a separate issue from what we’re discussing in this thread.

@Joe_Groff

One way we could potentially phase this in could be to start warning about import statements that don't specify a visibility in Swift 6, encouraging existing code to audit the visibility of their imports, and then changing the default in Swift 7 so that imports are implementation-only by default.

One of the reasons I think we can get away with this change is that in app targets, you almost never need to write public import.* If Swift 6 mode warns about un-annotated imports, the proposal changes from “some imports, mostly in libraries, need to be marked with an additional keyword” to “every import in every file needs to be marked with an additional keyword”, and given how long it took to get from Swift 5 to Swift 6, waiting until Swift 7 to finish the transition could mean we spend several years in that state. I think that might tip this change from a minor inconvenience to a major hassle.

* It actually just occurred to me that even in app targets, retroactively conforming types you don’t own to protocols you don’t own would require a public import of both modules. This is arguably a feature.

@Jumhyn

Do we have hypotheses about what proportion of bare import s today should be internal import s versus public import s? If we expect there to be a nontrivial number of bare import s that really should have been internal / @_implementationOnly , it still seems like quite the burden to me to have users to add internal to every one, especially when they'll probably just want to take them away in the next language version anyway.

My back-of-the-envelope hypothesis is that more than half of imports in libraries will need to become public imports, but very few imports in executables or test suites will need to change. This is not based on any data; I should probably instrument the compiler in a branch (e.g. repurpose the existing @_implementationOnly checking to emit a remark on normal imports that would need to become public) and then build the Source Compatibility Suite to get some numbers.

@allevato

Do you envision SPM extending targets to have separate dependencies and publicDependencies lists to make similar optimizations to its compiler invocations?

This is a really good question that I haven’t even thought about.

@jrose

The semantics don’t quite match up with access control, though. Everywhere else, access control governs visibility; in that model, a private (= fileprivate ) import is what we have as the default today (ignoring the extensions-and-operators behavior), an internal import would make a module visible to all files in the target (which has been requested), and a public import would be visible outside of the target as well.

This is true. I guess my mental model is that <access-level> import M doesn’t mean “make this import visible at <access-level>; it means “import public declarations from M into this file as though they have <access-level> or less”. That is, (absent @exported) import is always inherently a per-file thing, and the access control keyword is being transitively applied to what’s being imported. (Although that gets a little weird with open.)

@jrose

That said, I also think this would be a good time to fix the extension and operator leakage. It’ll be annoying but the compiler has the right tools for it now.

Incidentally, I learned recently that @hamishknight at least partially fixed the operator visibility logic last year, but there’s some compatibility logic to retain the old behavior and a feature flag to disable it.