search

swiftlang / swift

The Swift Programming Language
https://swift.org
Apache License 2.0
67.58k stars 10.36k forks source link

[SR-10578] We should have NS_CLOSED_ERROR_ENUM #52978

Open 05262b81-54a9-4fe1-bf6a-96f8042de10e opened 5 years ago

05262b81-54a9-4fe1-bf6a-96f8042de10e commented 5 years ago
Previous ID SR-10578
Radar None
Original Reporter @lilyball
Type Improvement
Additional Detail from JIRA | | | |------------------|-----------------| |Votes | 0 | |Component/s | | |Labels | Improvement | |Assignee | None | |Priority | Medium | md5: 3121bbee1a033124a692365436f30c0e

Issue Description:

In order to interoperate with Swift, Obj-C gained the NS_CLOSED_ENUM macro for declaring a C enum that has "closed" semantics, and it gained the NS_ERROR_ENUM macro for declaring a set of NSError error codes that automatically get wrapped into a Swift error type. Unfortunately there seems to be no NS_CLOSED_ERROR_ENUM, which means when I consume the Swift error type I need an @unknown default case despite the error type originating from my own application code.

Just as we support NS_CLOSED_ENUM both for application developers and for libraries that promise to never introduce new cases, we should support NS_CLOSED_ERROR_ENUM.

05262b81-54a9-4fe1-bf6a-96f8042de10e commented 5 years ago

I realize this is a change that needs to be made on the Obj-C side, which hopefully zero changes on the Swift side (as a closed enum is ultimately just an attribute, which the NS_CLOSED_ERROR_ENUM macro would add), but since the previous macros were driven by Swift needs I figured it was appropriate to put this here. And who knows, maybe we need to teach ClangImporter about this new macro anyway, as I seem to recall it knew how to identify previous Swift-compatibility macros for some reason.

belkadan commented 5 years ago

Yeah, these days you can construct it yourself with the two attributes enum_extensibility(closed) and ns_error_domain(…). I don't think we considered NS_CLOSED_ERROR_ENUM at the time because it's rare to switch exhaustively over an error enum (and will likely never happen for any of Apple's public error enums), but I guess it's something you can do if you control the enum too.

Since there's nothing to change on the Swift side, do you want to file the Radar or should I?

05262b81-54a9-4fe1-bf6a-96f8042de10e commented 5 years ago

If you're willing to file the radar, I'd appreciate that. Thanks!