> On Mar 17, 2016, at 1:45 PM, Jed Lewison <[email protected]> wrote:
>
>> On Mar 17, 2016, at 12:16 AM, Chris Willmore via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
