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

[swift-ci]

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]

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]

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]

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!