[swift-evolution] [Draft] Abolish IUO type

[Jed Lewison]

Sounds good to me. I’ll admit, I’m looking forward to the day when you have to explicitly use the force operator if you want/need to unsafely unwrap optionals, but this seems like a positive step in that direction.

> On Mar 17, 2016, at 4:56 PM, Chris Willmore <cwillmore at apple.com> wrote:
> 
>> On Mar 17, 2016, at 1:45 PM, Jed Lewison <jed.lewison at icloud.com <mailto:jed.lewison at icloud.com>> wrote:
>> 
>>> On Mar 17, 2016, at 12:16 AM, Chris Willmore via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> To run with the example above, emailTextField would have type UITextField? but, because it’s an IUO declaration, it would still be usable in contexts that required non-optional UITextField. What would change is that if you were to say, e.g.
>>> 
>>> let textField = controller.emailTextField
>>> 
>>> then textField would have type UITextField?. But you could still say
>>> 
>>> formView.addSubview(controller.emailTextField)
>> 
>> For this scenario, would you be able to implicitly force-unwrap when a non-optional is not required, like:
>> 
>> 	controller.emailTextField.minimumFontSize = 12
>> 
>> Or would you have to say:
>> 
>> 	controller.emailTextField?.minimumFontSize = 12
> 
> The first one. The type-checked expression would force  controller.emailTextField.
> 
>> If the former, would fontSize be an Optional<CGFloat> or a CGFloat (non-optional)?
>> 
>> 		let fontSize = controller.emailTextField.minimumFontSize
> 
> It would be a (non-optional) CGFloat. Neither of these is different from current IUO behavior.
> 
>> As a user, I’m not sure which I’d expect. Given the behavior of let textField = controller.emailTextField, it seems like i’d expect fontSize to be an Optional<CGFloat>. Then again, if I’m allowed to implicitly unwrap emailTextField, it also doesn’t make any sense for fontSize to be an Optional.
> 
> Yes, this is a little weird. But any attempt to remove the IUO type from the Swift type system, without removing the notion of IUOs entirely, runs into this sort of substitution-principle violation. It is not possible to pull an IUO sub-expression of an expression out into a temporary variable and have it type-check the same way without inferring the intermediate variable as IUO as well, a behavior that we explicitly wish to avoid.
> 
>> (I’m assuming that there would not be a circumstance where the IUO-ableness of the value would be preserved.)
> 
> The variable that the value is bound to could be explicitly marked as IUO. Otherwise, you’re correct.
> 
>> On a different note: As a general rule, I’m +1_000_000 on anything that makes IUO and force-unwrapping less common, so anything with the subject “Abolish IUO Type" makes me smile.
> 
> I’m glad we both feel that way!
> — Chris Willmore

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160317/17f5c29a/attachment.html>