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. -- Chris Willmore > On Mar 31, 2016, at 9:43 AM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > Proposal Link: > 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] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
