On Apr 21, 2016, at 3:12 PM, Chris Willmore via swift-evolution <[email protected]> wrote: > I evaluated the effects of this proposal on five projects written in Swift > against Foundation and other well-audited OS X and iOS Objective-C APIs. The > only changes that had to be made were the result of Objective-C API in the > project itself that had not yet been annotated with nullability information. > In addition, it ended up revealing a programming error in one project where a > property had been unintentionally inferred to have IUO type. I presented > these results at the Swift core team review meeting. > > Jordan Rose expressed some concern that this sampling of projects didn’t > really say anything about the effect of these changes on projects that depend > on unaudited API, especially the Linux case. So I investigated the effect of > this proposal on building swiftpm, which makes extensive use of POSIX C API. > It ended up requiring ten new uses of the ! operator (out of 14k lines of > Swift) to get building again; they were all return values from C API > (ctime_r, getcwd, getenv, strerror, realpath) that had been saved to > intermediate variables. Jordan observes that most of the cases are better > expressed with “if let” or “guard let” statements anyway. > > We have concluded that we should move forward with implementing the proposal.
Thank you for doing this extra analysis Chris, and thank you also for driving this whole effort forward! -Chris > > -- Chris Willmore > >> On Mar 31, 2016, at 9:43 AM, Chris Lattner via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> Proposal Link: >> https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md >> >> <https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md> >> >> The review of SE-0054 "Abolish ImplicitlyUnwrappedOptional type" ran from >> Mar 25…30, 2016. The proposal has been *accepted, pending implementation >> experience*: >> >> There is generally positive feedback on the proposal, as it keeps the good >> behaviors of the existing T! type syntax (including support for importing >> un-nullability-audited APIs, support for 2-phase initialization patterns, >> etc) while dramatically reducing the confusion and surprise that they >> introduce as they trickle through type inference. The core team sees >> significant value in having a simple and predictable model that can be >> explained concisely. >> >> That said, this is the sort of proposal that can have a profound impact on >> the actual experience using unaudited APIs. The core team believes that the >> experience will be good, but we would like to get some experience moving a >> couple of existing projects (both low-level code that interacts with C, and >> an “App” project working with high level frameworks) to see what the impact >> is in practice. If something unexpected comes up, we will revisit this, and >> potentially reject it later. Chris Willmore is working on an implementation >> of this now, so we should know in the next week or two. >> >> Thank you to Chris Willmore for driving this forward! >> >> -Chris Lattner >> Review Manager >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > 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
