[swift-evolution] [Draft] Abolish IUO type

[Chris Willmore]

> On Mar 17, 2016, at 1:45 PM, Jed Lewison <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/27fd279e/attachment.html>