Exactly. The issue here isn’t the standard library, or Apple frameworks that ship compiled with the OS. The issue is packages that ship as code and are compiled together with the code that uses them. That’s where the potential for breakage is.
I believe library consumers would want a tool to reject or accept libraries using unstable language features, regardless of their SemVer claims. That way, consumers can manage their own risk. A community-built tool could integrate with dependency-management and add metadata to package registries.
Aside from the value to consumers, outing libraries might discourage using unstable features. Conversely, permitting consumers to expressly opt-in might permit libraries to progress their versions to 1.0+ based on supported API's, with an unstable-feature proviso. And decisions about the unstable feature could be informed by data about its prevalence.
In either case, I think the core team has spoken, and noncompliance, however prevalent, is uncooperative and steals resources.
We need unstable features for experimenting, and we need stable libraries for scaling. I think consumers know which mode they're in, so they're in a good position to decide, and library authors can follow their consumers.
No, the issue exists in all code which uses these attributes, binary and source alike. A change to the public interface of the standard library would break compilation just like a change to the source of libraries. It's for exactly that reason that actual changes to these attributes are extremely unlikely without an upgrade path.
I would argue such a position is actually more unhealthy for Swift and the Swift ecosystem than the problem it purports to correct. Swift is not Rust. These are not strictly experimental features with well defined scopes. Many of these features, like _modify, are the only way to get Swift to work well in certain areas. Discouraging the use of them essentially freezes the ecosystem in very bad place for the language. Unless you think doing so would encourage the finalization of those features by Apple, which I don't, I can't see an upside to your proposal.
3 Likes
This is my hypothesis as well. We have Swift Source Compatibility that makes it trivial to spot compiler regressions. Note that NIO, Swift Collections, Alamofire, GRDB, RxSwift, and many more libraries that are widely used in the community are there. By registering in this list, the library authors made their part of the job.
As for underscored attributes used by GRDB, I can quote:
@_exported: Not strictly necessary, but it helps GRDB users use CocoaPods, SPM, or direct Xcode project integration in order 1. to access system SQLite, SQLCipher, or custom SQLite builds, or 2. change their installation method, without churn: justimport GRDBand you're good to go.@_disfavoredOverload: Required in order to work around compiler bugs such as SR-15150. I also see one usage of this directive commented with "Avoid a wrong resolution when BUILD_LIBRARY_FOR_DISTRIBUTION is set" in the GRDB source code, and I guess I could have filed a compiler bug for this one as well. Finally this directive is required in order to help the compiler resolve ambiguous apis.@inline(__always): performance matters. Library authors profile their code, inspect assembly, and have to make decisions.
I also wish, of course, that the language would fix those holes as quickly as possible.
At the same time, I understand, of course, that it is a matter of allocation of resources.
I also understand that it takes time to fully understand what a feature is exactly about, and I'm not surprised those attributes are still underscored. We can all witness that the compiler is evolving independently of Swift evolution, and I'm pretty confident part of this silent work is setting up the stage for our requests.
Finally, it's difficult to ask the Core Team for commitment about the stability of those underscored attributes, because these underscores are their escape hatch. Practically speaking, the features they enable are there to stay, so I don't worry much. Everything @Jon_Shier has said is exactly what I foresee.
My final word is for library authors: please do register your code into Swift Source Compatibility!
5 Likes
Including, very precisely, this sentence:
This is spot on. Part of the popularity of some libraries is the confidence, acquired over the years by their users, that library authors maintain their libraries and don't let their users down.
If the language were hostile, library authors could just give up, especially the unpaid ones. But so far the language has reasonably plaid its part in the score, and library authors could acquire, over the years, the confidence that the language is a partner (even if it has rough edges).
This environment of confidence (users -> libraries -> language) is a crucial asset. It is much stronger than:
There are no source stability commitments when it comes to underscored keywords or attributes and no-one should have any expectations in this regard, either at compile time or runtime.
1 Like
Putting a pause on this thread.
8 Likes