[Accepted, pending implementation] SE-0054: Abolish ImplicitlyUnwrappedOptional type


(Chris Lattner) #1

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


(Shawn Erickson) #2

On the topic of unaudited APIs. Does a recommended way exist that I as say
a user of on an unaudited C API / library can add attributes to the C API
for my use in Swift? (e.g. code that I don't own, I just use)

It is likely a number of C APIs won't get attributed for improved use in
Swift by the authors so having a good way that the community could overlay
attributes for the benefit of Swift could be helpful.

Anything better then cloning headers?

-Shawn

···

On Thu, Mar 31, 2016 at 9:43 AM Chris Lattner <clattner@apple.com> wrote:

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.


(Fabian Ehrentraud) #3

Great to hear IUOs losing ground :slight_smile:

Might adding additional compiler warnings as described in SR-104 accompany the implementation of this proposal well?
https://bugs.swift.org/browse/SR-104

Fabian

···

On 31.03.2016, at 18:43, Chris Lattner via swift-evolution <swift-evolution@swift.org<mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Willmore) #4

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 <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Russ Bishop) #5

This seems like it would be a useful facility in general - the community may be able to provide audited headers even if the maintainers of the original project have zero interest in merging those changes. That burden is unreasonably high if it requires constant merging of the headers.

Russ

···

On Mar 31, 2016, at 2:24 PM, Shawn Erickson via swift-evolution <swift-evolution@swift.org> wrote:

On Thu, Mar 31, 2016 at 9:43 AM Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
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.

On the topic of unaudited APIs. Does a recommended way exist that I as say a user of on an unaudited C API / library can add attributes to the C API for my use in Swift? (e.g. code that I don't own, I just use)

It is likely a number of C APIs won't get attributed for improved use in Swift by the authors so having a good way that the community could overlay attributes for the benefit of Swift could be helpful.

Anything better then cloning headers?

-Shawn
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #6

We have a facility for doing this (called “API notes”). The problem is that it is currently hacked together to solve specific problems, not something that is really properly designed.

I know that many people would like to see this situation get improved, and make it a first class feature of the swift experience.

-Chris

···

On Mar 31, 2016, at 2:24 PM, Shawn Erickson via swift-evolution <swift-evolution@swift.org> wrote:

On Thu, Mar 31, 2016 at 9:43 AM Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
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.

On the topic of unaudited APIs. Does a recommended way exist that I as say a user of on an unaudited C API / library can add attributes to the C API for my use in Swift? (e.g. code that I don't own, I just use)

It is likely a number of C APIs won't get attributed for improved use in Swift by the authors so having a good way that the community could overlay attributes for the benefit of Swift could be helpful.


(Chris Lattner) #7

Great to hear IUOs losing ground :-)

Might adding additional compiler warnings as described in SR-104 accompany the implementation of this proposal well?
https://bugs.swift.org/browse/SR-104

This is definitely related, but orthogonal to SE-0054.

Just MHO, but I think warning on every implicit unwrap would completely defeat the point of having the T! feature in the first place: if that were the model we wanted, we would just import unaudited pointers as optional. Doing that has been extensively discussed and is not a good idea.

-Chris

···

On Mar 31, 2016, at 11:43 PM, Fabian Ehrentraud <Fabian.Ehrentraud@willhaben.at> wrote:

Fabian

On 31.03.2016, at 18:43, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #8

NICE!

···

on Thu Apr 21 2016, Chris Willmore <swift-evolution@swift.org> 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.

--
Dave


(Chris Lattner) #9

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

···

On Apr 21, 2016, at 3:12 PM, Chris Willmore via swift-evolution <swift-evolution@swift.org> wrote:

-- Chris Willmore

On Mar 31, 2016, at 9:43 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution