But it is a fairly big change and adds some new features to Swift. Should it go through the Swift Evolution Process? cc @beccadax
Swift Evolution Process
Scope
The Swift evolution process covers all changes to the Swift language and the public interface of the Swift standard library, including new language features and APIs (no matter how small), changes to existing language features or APIs, removal of existing features, and so on.
But I did not find any forums pitches or discussions on this.
Does this mean the PR can be merged without going through Swift Evolution Process? (Another kind of good faith guess is that the author may be prepared to complete most of the PR work before presenting a pitch in the forum)
If it indeed does not need to go through Swift Evolution Process, what is the exception boundary on this? (Or what is the boundary of Apple's employee permission on adding new features to Swift freely?)
Sorry if the above sentence sounds offensive to whoever reads it. But I just want to communicate the rules frankly.
My guess is this PR only evolves changes in ObjC-supported platform (Darwin OS).
So does this imply if a feature is only useful or available on Darwin OS, it will not need go through Swift Evolution Process?
It’s not an “official” feature, it’s underscored which means it’s not meant for public use (just like all the other underscored features like _implements). So I don’t think it needs to go through Evolution.
As mentioned by others, underscored and/or experimental-flag-gated features are not considered part of the "public interface" of the standard library or language, and are not expected to go through evolution review. There is no special dispensation under the evolution process for Apple employees to add official language features without going through evolution review. (That said, Apple is of course the project lead and has ultimate authority over the language, including the evolution process itself.)
Any underscored/experimental features which have not gone through evolution review are not subject to guarantees that official language features have such as source stability and anyone who chooses to use them should be prepared for arbitrary behavior changes or complete removal at some point in the future.
No, this is not generally the case. Objective-C interop on Apple platforms is considered part of the public interface of the language and changes to the Objective-C interop behavior have gone through evolution review severaltimespreviously.
Given the facts that so many end users(including App Store Apps) use some underscore attributes so heavily, it will not have too much room to just delete it or change it.
The only solution IMO is deprecate the old one and delete it or formalize it to the language in a next major version of Swift (Source breaking change).
But if we consider delete or modify a underscore attribute to be a source breaking change, it is very not that much different from an "official" feature.
And I believe @_objcImplementation will be very likely to be the next one if we do not delete it nor formalize it, and just keeps it as underscore attribute for a long time.
People who maintain a massive ObjC codebase will eventually can't resist the temptation to use it when years later he/she saw so many usage on the Swift community.
And at point, will we still say@_objcImplementation is not an "official" feature yet?
Underscored attributes are not officially part of the Swift language and as such not covered by the source stability guarantee. The removal or modification of such features would not be considered source-breaking.
Yes. Developers should not expect to use underscored/experimental features and never have to remove/replace them.
I think in the case of these 2, the low-friction addition of underscored attributes was a fine way to start, but IMO these are serving enough of a need that I would like to see these formalized. Which I imagine could happen with any underscored attributes over time. IIRC @_functionBuilder -> @resultBuilder was developed this way as well.
A potential problem with this approach is that it may underestimate the value the community could bring to the fundamental stages of a feature’s formation.
If they don’t generally already, underscored features could have a pitch or some other write up shared around the time of initial work (the conversation around variadic types is a good example of this). These conversations may reduce the situation where the community is forced to accept a feature as is because the implementation is “too far gone”.
I like that the PR in this case has a good description that has stimulated conversation within observant members of the community. But it seems the motivations, alternatives etc still remain opaque and the community left out. Having this might also explain why the two month old PR is still open and if this is much ado about nothing
No, not at all. It means that sometimes platform vendors need features that would not pass Evolution review because they are not particularly useful for other developers, and in those cases, we sometimes allow them to implement these features for their own use, mark them internal-only, and maintain/change/remove them according to their own needs.
Is that what I'll be doing with @_objcImplementation? I'm not sure. It's a bit of a niche feature—probably only of interest to people who have Objective-C frameworks that they distribute to third parties as binaries—so I'm not sure if it would be widely used enough to convince Evolution that it's worth adding. But I intend to post a pitch thread to see if there's a bigger appetite for it than I thought.
As a preview of that thread, those of use who are migrating Very Big Apps would probably have jumped on this several years ago, but at this point I suspect most of us have taken the brunt of the pain already.
(In my particular case, we prefer partially-migrated features to have Swift interfaces over ObjC code rather than the other way around, and if we had had this four years ago it might have been used as a crutch to prop up mountains of questionable OCMockito mocks, so I’m not too sad we didn’t.)
This is only a concern for projects which are distributed as source code - and especially for public packages, because they form part of an ecosystem.
If Apple (or anybody else) wants to implement features for their internal libraries which are distributed as binaries, it generally doesn't impact anybody else, as long as it doesn't change the language syntax for clients and create a dialect.
I still think the proliferation of unstable language features in the package ecosystem is a very sad state of affairs, as is the lack of concern among package authors and the core team, as is the general lack of motivation towards stabilising those features. But it doesn't apply here unless/until people start publishing source code using the feature.
One thing I've suggested before is that these features should be opt-in with special compiler flags (-enable-experimental-objcimplementation or similar). I think that should be easy enough for a vendor like Apple to integrate in to their build system, while discouraging use of the feature generally by public source packages.
Speaking of it, is there any evolution proposal or doc for ObjectiveC's Protocol in Swift?
We only have a very short doc about it - Protocol | Apple Developer Documentation .And know we can pass a XXProtocol.self in Swift to make a call to an API which accepts Protocol as a parameter.
Yes. It is very usefully even if we do not distribute Objective-C binary frameworks.
For a company with extensive legacy Objective-C code(Hundreds of Objective-C Pods), transitioning to a mix of Objective-C and Swift is not an easy task. The introduction of the @_objcImplementation feature can significantly reduce the friction.
For example, let's consider module A written in Objective-C and module B written in Swift (where A depends on B). Due to the inability to rewrite everything in A and the inability to replace the .h file in module A directly, we could not use Swift-only features in module B's public interface (such as public Swift protocol and Swift generics).
However, with this feature available in Xcode 14.3 or Xcode 15 toolchain, we can use Swift-only features in module B's public interface as long as they do not appear in A's public interface. We could use such Swift-only features of B in A's m file by utilizing the @_objcImplementation Swift file.
This is an exciting feature for companies with large Objective-C codebases, particularly in China's iOS commercial market where Objective-C still holds a surprisingly high share compared to Swift, as seen in companies like Alibaba, ByteDance and Tencent.(Their product includes AliPay, WeChat and Chinese version of TikTok) Most of the feature on their app is still developed by ObjectiveC instead of Swift due to the immature of ObjC-Swift interop support for their use case.
Personally, I think it is worth pitching it publicly to be a former Swift feature so that everyone can use it.
