I think that @_spi attribute is enough for manipulation with API access. Yeah, for Open Source projects you can't guarantee, that user will not use your "secret" name for @_spi attribute in his project, but it's ok for open source, I think :)
Of course package can grant you, thats your API will closed from your package on compile time and nobody can't change that, but we really need this?
-1 for me
I've! I want to store helper packages outside from my Sources folder and configure them separately :) Sometimes I look into Firebase repository and their Package.swift is a huge boy.
As a maintainer of multiple open-source projects in the past, I can say that this is certainly not "ok" and causes multiple issues and unneeded maintenance burden. I don't see anything positive in users importing symbols that were meant to be internal to a package by accident, relying on them without maintainers being able to prevent it, and then reporting bugs if they find something's broken due to violated SPI assumptions.
This proposal doesn't suggest removal of @_spi (as an underscored attribute it can be removed without a proposal anyway) and is not meant to be a replacement for @_spi. But if you're not interested in using package for your specific use case, I don't think it's fair to dismiss other cases where it's clearly needed.
I don't think there's anything that prevents Firebase from creating multiple packages in their single repository and adding dependencies between them through local relative paths. AFAIR SwiftPM supported it right since the beginning if not since some of the earlier Swift versions.
Local relative paths are illegal for a tagged version (because of their ability to escape the package). So you can do this with embedded samples that depend on the root package (albeit escaping swift build), but you cannot have the root package depend on something embedded unless the package never tags any versions and is only used in other ways.
I think there's merit in this grammatical criticism too, but packageprivate is a mouthful and it's strange to have internal between it and private.
How about packagewide? The -wide suffix is standard English, meaning "throughout an area".
public struct MainEngine {
...
packagewide func run() { ... }
}
(Aside: Digging through the archives, it looks like I preferred filewide over fileprivate when that keyword was being chosen. Some things never change...)
I think I'd prefer the parameterized version. The two attributes are extremely similarāunifying them allows us to teach one concept instead of two.
My first thought was that this was backwards from e.g. private(set), where the access modifier appears before the argument list, not inside it. But in fact I think this isn't true. Attributes come before modifiers, and modifiers come before declaration keywords, so there is a consistent rule: the keyword that would normally come later is the argument.
// `set` would come after `private`, so it's `private(set)`:
public private(set) var x: Int
// `package` would come after `@usableFromInline`, so it's `@usableFromInline(package)`:
@usableFromInline(package) internal var y: Int
Overall Iām +1 on this proposal. But the very sentence in above quote proves in my opinion why āpackageā isnāt the right naming. A helper function āisā package? That sentence doesnāt make any sense. But a function āisā private or public or open or internal. Makes totally sense!
As already suggested in the pitch, I prefer one of:
packageinternal (clearest, but a bit long)packagewide (clear & short enough)widened (compared to to the default internal, the scope is "widened")A function āisā packagewide? Works again.
I just asked ChatGPT for inspiration, here are some more alternatives to consider:
I like variants 1, 2, 3, and 8.
[Full chat history:
Has it been considered to brand this keyword as external? It definitely resembles that type of visibility, but it can still be lower than public.
public > external > internal > private
^ everywhere
^ package
^ module
^ scope (but should really be on type level)
Or even possibly as central?
+1 for external as a possible alternative to package, especially as it mirrors internal. widened feels very out of place and weird to me.
I dunno man, once we start letting AI design the programming languages, Skynet can't be that far off. 
I don't think abbreviations like "pkg" are a good fit for the language (might even be an official antigoal).
If yet another level is really necessary (I feel no such need), this would be a good moment to reconsider the whole concept of access control, which has changed quite a lot from the simple beginning (same file < same module < everywhere).
It is a valid point that package is a bit different than open, public, internal, fileprivate and private, but I would say "this function is package" is not the only way of addressing a function's accessibility.
I believe you could say:
In this case, package is not so confusing. I would also say, it is the closest word to what it entails, inside a "swift package".
I would love to hear more opinions on the proposed keyword but branded as external before this review comes to an end.
internal is "inside a module", while external is "outside the module, but not fully public" and therefore the only place it can exist in, is inside a package. One could think that external implies public, but I don't think this is generally true. That's why this seems to be the perfect fit for this proposal if you'd ask me.
I'm -1 for external as it is not mutually exclusive with public and open. To me, everything that is not internal is considered external, and that would make it more confusing than package.
But I like the idea of using the same naming that we already have and their antonym. In that case I feel happier with closed rather than external, which is opposing open.
open > public > closed > internal > fileprivate > private
A type that is open, you can see it as an outsider (or subclass in case of classes)
A type that is public, you can only see it as an outsider.
A type that is closed, you can not see it as an outsider, only trusted few can.
It also resembles closeness of modules/packages together. And IMHO it is kinda mutually exclusive with internal and private, as it just describes that it is not accessible from outside world, but yet again, I think it's just preference, technically same argument can be used for closed.
I appreciate your feedback. Re "closed": While this looks fine on the spectrum of linear access modifiers, it's very much confusing in code. In fact public does already imply closed behavior in the context of disallowing to subclass from a public class. I wish this would have been done for protocols where a public protocol would mean that it's visible and you can use it algorithmically, but you cannot conform to it ("closed protocol"). In the flip side an open protocol would permit conformance to that protocol from outside. Unfortunately that ship sailed with the introduction of open. 
All this just shows that the whole access modifier topic is is very inconvenient from many perspectives. I really wish we could finally overhaul it once and for all with the Swift 6 language mode and keep the old behavior only in previous language modes.
There's so much that this can enable in the context of library development, but right now we're just stuck in front of a dead end.
Just to comment my thoughts on this for other review readers.
As I mentioned above, I don't think "external" is generally equals "public". Think about it from a different perspective. If you're working in a small team (that's your "module") inside a company (that's your "package") and you need to make your project available "externally". This does not imply that the project will be available outside of the company itself (that would be "public"). It's only made available externally for other teams to use (so it remains within the realm of a "package").
One could say that, but how often does anybody actually do so? Itās not a coincidence that the existing accessibility modifiers are adjectives.
Iām +0.5 on āexternalā: Itās better than āpackageā and when compared to āinternalā which is already scoped as āinternal to this moduleā, it makes sense as it means āexternal to this moduleā, which is correct. But Iām not 100% into it, because even āexternal to this packageā doesnāt specify where the accessibility ends, and thatās the most important aspect of an access modifier IMO.
Hereās another naming idea which is pretty close to the original name but also contains a similar notion to āinternalā: inpackage.
Yes, āinpackageā isnāt a real word and it could be written as āinPackageā to be more clear about the word boundaries, but we already have āfileprivateā which also isnāt a word and it also doesnāt use camel casing.
What do you think?
How about public(package)?
public(package) var example: Int
public(package) private(set) var example: Int
public(package) internal(set) var example: Int
public public(package, set) var example: Int
This would fit with the suggestion from the future directions section to use open(package) to restrict subclassing to package modules.
// Visible inside package, subclassable inside package
open(package) class Example {}
// Visible outside of package, subclassable inside package
public open(package) class Example {}
I see this:
as continued evidence that package is not the right name, even if adding a keyword for this exact access control setting is a good idea.