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

[weissi]

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]

@swift-ci create

[weissi]

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

[weissi]

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]

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

[Lukasa]

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]

thank you @Lukasa!

[QuietMisdreavus]

This is affecting Swift-DocC as we try to expand our data model (cf. swiftlang/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.