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-9516] Assigning an implicity unwrapped optional should unwrap it #51968

Open
swift-ci opened this issue Dec 14, 2018 · 3 comments
Open

[SR-9516] Assigning an implicity unwrapped optional should unwrap it #51968

swift-ci opened this issue Dec 14, 2018 · 3 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-9516
Radar None
Original Reporter jalkut@red-sweater.com (JIRA User)
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: ea6b3507dbe39e8fbf87a0bf6925e4a4

Issue Description:

When working with an implicitly unwrapped optional, I think that assigning the value to another variable should either unwrap the optional, or perpetuate the compiler's understanding of the optional as being implicitly unwrapped.

When working with an implicitly unwrapped optional, it's common to treat it as effectively non-optional. Here's a contrived scenario where a random value is chosen from between two derived values: one an IUO, and the other non-optional:

func takesAnInt(theInt: Int) { print("Got \(theInt)") }

let neverNil: Int! = 3
let alsoNeverNil = 5

let randomNeverNil = Int.random(in: 0...1) == 0 ? neverNil : alsoNeverNil

// Error: randomNeverNil not unwrapped
takesAnInt(theInt: randomNeverNil)

In this kind of scenario, care should not need to be taken to either additionally check for nil, or force-unwrap randomNeverNil. In my opinion the contract for an IUO is that it will be unwrapped when used, and that assigning it to another variable is as good an example of using it as passing it as a value to a function.

The practical scenario I run into this most is with IBOutlets that are IUO. I am liable to assign the property value to a local variable inside a function, only to be forced to unwrap it before passing it to another method.

@swift-ci
Copy link
Collaborator Author

Comment by Daniel Jalkut (JIRA)

It was pointed out to me that assigning to an explicitly non-nil type works around the problem:

let randomNeverNil: Int = Int.random(in: 0...1) == 0 ? neverNil : alsoNeverNil

I still think it would be NICER if the inferred type were Int.

@belkadan
Copy link
Contributor

The logic here is that an IUO is only forced if that's the only way to make an expression correct (see https://swift.org/blog/iuo/). I do see how that's annoying in this case, but it's a rule that errs on the side of compiler diagnostics rather than run-time traps.

Stepping back, since this could break source compatibility it's the kind of change that would have to be discussed at https://forums.swift.org, and probably go through the full Swift Evolution Process.

@swift-ci
Copy link
Collaborator Author

Comment by Daniel Jalkut (JIRA)

Thanks for the perspective @belkadan. Now that I understand how it works I can probably just coddle it, but if anybody else cares to take up this mission I would be in support of their doing so!

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
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. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

2 participants