# SE-0409: Access-level modifiers on import declarations

**URL:** <https://forums.swift.org/t/se-0409-access-level-modifiers-on-import-declarations/67290>\
**Category:** Proposal Reviews\
**Created:** [September 15, 2023, 1:17am UTC](https://forums.swift.org/t/se-0409-access-level-modifiers-on-import-declarations/67290 "2023-09-15T01:17:50Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [September 15, 2023, 2:20pm UTC](https://forums.swift.org/t/se-0409-access-level-modifiers-on-import-declarations/67290/8 "2023-09-15T14:20:52Z")

</div>

> [@cal](#):
>
> Is it necessary to support both `private` and `fileprivate` if they have the exact same behavior? Could we pick just one to allow here?

This already exists in Swift today, because the same case could be made for _any_ `fileprivate` or `private` declaration at file scope. Unfortunately, I think that ship has sailed and having the inconsistency for `import`s would put us in a worse state than allowing the redundancy.

> [@michelf](#):
>
> I fear there's going to be a bit of confusion about the meaning of those access modifiers. The access levels on declarations currently relate to the visibility of the declaration. If you declare an `internal` type for instance, the type becomes available anywhere in the module. Wouldn't an `internal` import makes the imported declarations available anywhere in the module too? This is obviously not what is proposed here.

This concern was raised in the pitch thread as well, but to reiterate [what I said there](https://forums.swift.org/t/pitch-access-level-on-import-statements/66657/19), I don't think there's a world where it's desirable to have imports from one file affect type checking in other files in the same module. That would make it very difficult to reason about the contents of a file on its own and would also be harmful to incremental compilation.

I think the proposed spelling is both concise and clear ("if you import `M` with access level `L`, then you can use `M`'s types in the signatures of your own `L` or lower declarations") and I don't think we'd gain clarity by making it more verbose. `public import` will be very common in Swift 6 when using imported APIs as part of your own, and I'm not convinced that the use of `pub(lic)` by other languages to mean `@_exported` is evidence enough that we should use `public import` for _that_ in Swift and have to come up with another, more complicated way to spell the _proposed_ `public import`.

---

_[View the full topic](https://forums.swift.org/t/se-0409-access-level-modifiers-on-import-declarations/67290)._