Non-frozen enums in Swift

christopherma_backbase · 2023-01-10T09:06:01.449Z

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.

hassila · 2023-01-10T09:23:20.022Z

You’d need to use library evolution support.

See some background here:

Swift.org – 13 Feb 20

Library Evolution in Swift

Swift 5.0 introduced a stable binary interface on Apple platforms. This meant that apps built with the Swift 5.0 compiler can use the Swift runtime and standard library built into the operating system, and that existing apps will remain compatible...

(There are several caveats though - one of the biggest ones that this is not yet fully supported cross platform yet)

christopherma_backbase · 2023-01-10T09:31:56.901Z

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 · 2023-01-10T09:46:41.834Z

You might also want to check out eg.

github.com/apple/swift-package-manager

Dynamic library support on Linux with library evolution

opened 10:45AM - 09 Aug 22 UTC

hassila

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

github.com/apple/swift

Availability annotations for third party libraries when using Library evolution/ resilience

opened 10:27AM - 09 Aug 22 UTC

hassila

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.

christopherma_backbase · 2023-01-10T09:57:56.306Z

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 · 2023-01-10T10:06:09.436Z

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.

Karl · 2023-01-10T10:53:45.524Z

Extensible Enumerations for Non-Resilient Libraries Pitches

Hey folks. Over the weekend I put together a quick draft patch that would enable non-resilient Swift libraries to provide "extensible" enums, where adding a new case would not be a Semver major breaking change. This patch does the absolute minimum required to enable the functionality, so before I go any further with it I wanted to get the community's opinion on whether this is a problem worth addressing. Below is a draft proposal that covers the issue. Please give it a read and let me know your…

hassila · 2023-01-10T11:11:08.888Z

That’d be much more lightweight for some use cases, thanks for the pointer.