I love the revision to the proposal
<https://github.com/apple/swift-evolution/pull/777>, but I have a couple of
remaining questions that don't seem to be addressed in the doc and I'm
curious about:
- What happens if a library maintainer adds a new case to a *@frozen*
enum?
- What happens if a library maintainer changes an enum from *@frozen* to
non-frozen?
Thanks!
--
Ignacio Soto
This is the same issue as when a library maintainer changes a class from open to closed.
On Jan 5, 2018, at 10:54 AM, Ignacio Soto via swift-evolution <swift-evolution@swift.org> wrote:
I love the revision to the proposal <https://github.com/apple/swift-evolution/pull/777>, but I have a couple of remaining questions that don't seem to be addressed in the doc and I'm curious about:
What happens if a library maintainer adds a new case to a @frozen enum?
What happens if a library maintainer changes an enum from @frozen to non-frozen?
Thanks!--
Ignacio Soto
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Good questions. The answer at a high level is "you break binary and source compatibility", and if you care about binary compatibility everything will fall to pieces (read: crashes, possibly undefined behavior). So our only goal on the binary compatibility is to make the "falling to pieces" as deterministic as possible, as described as a "Future direction"; we want library authors to not do this by mistake, and if they do we want apps to fail to launch rather than potentially corrupting user data.
For libraries that don't care about binary compatibility, breaking source compatibility is an option, if not one to be taken lightly. So:
- Adding a case to a frozen enum will result in errors in all switch statements without catch-all cases ('default' or '_' patterns), with the diagnostic saying that there is now an unhandled pattern. This is essentially the behavior of enums in Swift 4.
- Changing an enum from frozen to non-frozen will result in errors in all switch statements without catch-all cases, with the diagnostic saying that a switch over a non-frozen enum must include a catch-all pattern or `unknown case`. This is the diagnostic people will see when migrating from Swift 4 to Swift 5, so it has to be good anyway.
I'll add this to the proposal. Thanks, Nacho!
Jordan
On Jan 5, 2018, at 10:54, Ignacio Soto via swift-evolution <swift-evolution@swift.org> wrote:
I love the revision to the proposal <https://github.com/apple/swift-evolution/pull/777>, but I have a couple of remaining questions that don't seem to be addressed in the doc and I'm curious about:
What happens if a library maintainer adds a new case to a @frozen enum?
What happens if a library maintainer changes an enum from @frozen to non-frozen?
Thanks!--
Ignacio Soto
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution