As I understand it, as a user of Swift, I can't define a non-frozen enum in Swift?
Presumably there's a reason for that? It would seem beneficial if we could as we could then avoid breaking changes in library APIs when adding new cases to the enum.
Currently a user of my library gets frozen enums which I may intend to add new values to in the future. They have to write exhaustive switch statements, which might take the form a listing our each possible case, with no default case, so adding a new value will break compilation.
In ObjC, or Apple's code, enums can be defined as non-frozen to avoid this issue.
1 Like
hassila
(Joakim Hassila)
January 10, 2023, 9:23am
2
You’d need to use library evolution support.
See some background here:
(There are several caveats though - one of the biggest ones that this is not yet fully supported cross platform yet)
Ahh nice, my sample library/app I was playing around with this in didn't have that enabled of course, but the production library should be able to
hassila
(Joakim Hassila)
January 10, 2023, 9:46am
4
You might also want to check out eg.
opened 10:45AM - 09 Aug 22 UTC
enhancement
### Description
# Background
We have an enterprise-style application where we … have a large number of libraries (swift packages) that we'd like to be able to evolve independently using library evolution and to dynamically link them to a large number of consumers.
Basically adding binary dependency support to a dynamic library generated using SPM similar to XCFrameworks.
I've read https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md and would like to suggest a first step could be to cater to this kind of 'enterprise' deployment scenario rather than taking on the full 'many linuxes support everywhere' - we have full control over deployment operating system and swift toolchain (we can mandate for our customers what they must have to run the software and would do builds for a small number of deployment environments that we support).
The artefact bundle format seems that it would suffice for such a scenario.
So trying to break down what's needed (perhaps missing something):
- Support for binary dependencies also for Linux (preferably using `artifactbundle` format so we can have both macOS and Linux in a single dependency if putting things in the right places)
- Support for enabling library evolution for SPM packages generating dynamic libraries on both macOS and Linux (accepting the requirement for same toolchain on Linux)
I think this single-linux-distribution as a first step could be very useful not only for us, but also for others - and help as a stopgap deployment measure.
See also related discussions / issues:
https://github.com/apple/swift/issues/60458
https://forums.swift.org/t/use-a-dynamic-library-in-a-swift-package-on-linux/59510
https://forums.swift.org/t/availability-when-using-library-evolution-resilience-for-third-party-libraries/59341/3
etc.
### Expected behavior
_No response_
### Actual behavior
_No response_
### Steps to reproduce
_No response_
### Swift Package Manager version/commit hash
_No response_
### Swift & OS version (output of `swift --version && uname -a`)
_No response_
And
opened 10:27AM - 09 Aug 22 UTC
new feature
**Is your feature request related to a problem? Please describe.**
We’ve ende… d up realizing we’d like to use the library evolution features for resilient api surfaces for our product (yes, needed for an enterprise solution where clients of libraries must be able to be replaced independently and don’t have source access. Both macOS and Linux. Aware of tool chain impedance matching on Linux required - that’s ok).
The question is how we can evolve our api with availability annotations?
Current annotations for availability is tied to platform or swift version only, but we'd want to tie it to our products version numbers instead.
Not sure the best way to express it, but if a typical swift macro would be:
`@available(swift 5.1)`
we'd want something like:
`@available(ourProductName 2.0)`
which we could use with e.g.
```
if #available (ourProductName 2.0) {
return x
} else {
return y
}
```
or e.g.
`@available(ourProductName , deprecated: 3, renamed: "newNameForThis")`
**Describe the solution you'd like**
Add support for third-party availability annotations to allow tying availability to our product releases instead of platform/swift versions.
**Describe alternatives you've considered**
As a stop-gap we considered to tie it to Swift releases instead, which is not really a good workaround, but AFAWU it's fundamentally the only option we have (for it to work on both Linux and macOS) - and not very good conceptually.
**Additional context**
Some background discussion here:
https://forums.swift.org/t/availability-when-using-library-evolution-resilience-for-third-party-libraries/59341
For at least two of the current caveats.
Thanks sharing! SPM and/or Linux aren't currently a concern and our current approach isn't affected by the second one I don't think (but either might apply to others reading of course!).
hassila
(Joakim Hassila)
January 10, 2023, 10:06am
6
If you want to do proper library evolution tied to versions of your library, I think the second one would be something that would impact.
hassila
(Joakim Hassila)
January 10, 2023, 11:11am
8
That’d be much more lightweight for some use cases, thanks for the pointer.