I was also surprised this type still exists as I'd taken that the proposal was for the removal of IUO as an explicit type, but after some testing of IUO propagation behaviour in Swift 3.0, I'm happy to report the behaviour has been changed to meet the desired behaviour in the spec, specifically, I now don't need to define a separate interface signature to specifically expect type T!
> On 21 Jun 2016, at 21:22, Joe Groff via swift-evolution > <[email protected]> wrote: > > >> On Jun 21, 2016, at 1:06 PM, David Hart via swift-evolution >> <[email protected]> wrote: >> >> Just saw this article about IUO in Swift 3.0: >> >> https://www.bignerdranch.com/blog/wwdc-2016-increased-safety-in-swift-3/ >> >> I was surprised that the IUO type still exists. From what I understood, >> SE-0054 gives a clear example that: >> >> func f() -> Int! { return 3 } >> // f: () -> Int?, has IUO attribute >> // ... >> >> let x3: Int! = f() >> // succeeds; x3: Int? = .some(3), has IUO attribute >> // ... >> >> func g() -> Int! { return nil } >> // f: () -> Int?, has IUO attribute >> // ... >> >> let y3: Int! = g() // succeeds; y3: Int? = .none, has IUO attribute >> >> x3 and y3 should be a of type Int? but trying those out in Xcode 8’s beta 1 >> playground show that they are still of type Int!. Did I miss something? > > SE-0054 hasn't been fully implemented yet. The stricter implicit promotions > are mostly there, but the IUO type still exists. > > -Joe > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
