Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SR-12666] Remove the open/frozen enum language dialect #55110

Open
weissi opened this issue Apr 24, 2020 · 7 comments
Open

[SR-12666] Remove the open/frozen enum language dialect #55110

weissi opened this issue Apr 24, 2020 · 7 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.

Comments

@weissi
Copy link
Member

weissi commented Apr 24, 2020

Previous ID SR-12666
Radar rdar://problem/62318713
Original Reporter @weissi
Type Bug
Additional Detail from JIRA
Votes 0
Component/s
Labels Bug
Assignee None
Priority Medium

md5: 13f02b076545191585eaef8de5234844

Issue Description:

Currently, Swift has at least two language dialects:

  • Swift with library evolution on (Swift+LE )

  • Swift with library evolution off (Swift-LE )

To my knowledge, there's only one semantic difference:

  • Swift+LE 's enum s are open by default and can be closed by using @frozen

  • Swift-LE 's enum s are closed by default and CANNOT be open

That leaves us in Swift-LE land in a terrible position (eg. apple/swift-nio#1428 , apple/swift-nio#969 ): Not only do we have a different default, Swift-LE actually literally cannot express the default behaviour of Swift+LE...
@weissi
Copy link
Member Author

weissi commented Apr 24, 2020

@swift-ci create

@weissi
Copy link
Member Author

weissi commented Apr 27, 2020

--> https://forums.swift.org/t/extensible-enumerations-for-non-resilient-libraries/35900

@weissi
Copy link
Member Author

weissi commented Jun 18, 2021

With SwiftCrypto (Swift-LE on Linux but Swift+LE on Darwin because it just re-exports CryptoKit) this is an especially annoying problem: https://twitter.com/krzyzanowskim/status/1405830734934331396

@weissi
Copy link
Member Author

weissi commented Jun 18, 2021

CC @jckarter/@tomerd Any chance this could be sorted out?

@Lukasa
Copy link
Contributor

Lukasa commented Jun 18, 2021

Concretely this does not really affect Swift Crypto. The only enums in the public API of CryptoKit are error enums, and they are essentially never switched over. This affects CryptoSwift, which Marcin maintains.

@weissi
Copy link
Member Author

weissi commented Jun 18, 2021

thank you @Lukasa!

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@QuietMisdreavus
Copy link
Contributor

This is affecting Swift-DocC as we try to expand our data model (cf. apple/swift-docc#358 (comment)). Since packages can't reliably enable LE (and LE is a wide swath of guarantees to add just for nonfrozen enums), we're stuck adding a hacky underscored "please use a default case" enum case instead.

@QuietMisdreavus QuietMisdreavus mentioned this issue Aug 24, 2022
Merged
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@weissi @Lukasa @QuietMisdreavus