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 <[email protected]> wrote: > >> On Mar 17, 2016, at 1:45 PM, Jed Lewison <[email protected] >> <mailto:[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
