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

[SR-1419] rawValue enum initializer does not fail for enums imported from Objective-C when given an invalid value #44028

Closed
swift-ci opened this issue May 5, 2016 · 3 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. CodeGen compiler The Swift compiler in itself standard library Area: Standard library umbrella

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented May 5, 2016

Previous ID SR-1419
Radar None
Original Reporter mgetz (JIRA User)
Type Bug
Status Resolved
Resolution Won't Do
Environment

XCode 7.3.1
Swift: 2.2

Additional Detail from JIRA
Votes 0
Component/s Compiler, Standard Library
Labels Bug, CodeGen
Assignee None
Priority Medium

md5: 62ca942b34051dc9fa0f59a32b3e7592

Issue Description:

Description:

The rawValue enum initializer does not fail as designed for enums imported from Objective-C when given an invalid value. It does however fail for enums that are Objective-C compatible or exported to Objective-C.

import Foundation

@objc
enum test: Int{
  case a = 0
  case b
}

let failtest = test(rawValue: -1)
assert(failtest == nil)

let failtest2 = NSRoundingMode(rawValue: UInt.max)
assert(failtest2 == nil)

Expected result:

code should succeed

Actual Result:

assert is triggered, testVal has a value of UInt.max

Notes:

This may be design behavior due to the fact that many imported NS_OPTIONS need this behavior. In order to maintain compatibility a second failIfInvalid:Bool parameter that defaults to false could be added to the generated init

@belkadan
Copy link
Contributor

belkadan commented May 5, 2016

There are too many enums in system frameworks with "private cases". At some point we might provide a way for Objective-C API authors to distinguish "closed enums" where the public cases really are exhaustive, but for now this behavior is expected. (It also matches the behavior in C.)

@swift-ci
Copy link
Collaborator Author

swift-ci commented May 6, 2016

Comment by Michael Getz (JIRA)

Can the interoperability documentation on apple website be updated to reflect this? Right now a user would have to google and find this bug to know this is by design behavior.

@belkadan
Copy link
Contributor

belkadan commented May 6, 2016

Good call. I'll pass it along to the people who maintain that document.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. CodeGen compiler The Swift compiler in itself standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

2 participants