You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
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!
Additional Detail from JIRA
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:
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.
The text was updated successfully, but these errors were encountered: