[Review] SE-0139: Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue


(Douglas Gregor) #1

Hello Swift community,

The review of SE-0139 "Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue" begins now and runs through September 7, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md
Reply text

Other replies
<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager


(Scott James Remnant) #2

:+1:

Makes ObjC APIs even easier to work with, without any cost to working with Swift APIs

···

On Sep 1, 2016, at 4:58 PM, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The review of SE-0139 "Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue" begins now and runs through September 7, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md
Reply text

Other replies
<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager

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


(Jaden Geller) #3

* What is your evaluation of the proposal?

I majorly support this proposal, particularly the completion of numeric bridging. I would almost regarding the existing behavior as a bug. As a user, I was very surprised that `Int8` and friends did not bridge to `NSNumber`, and it has actually been the source of bugs in production code for us. Prior to import `id` as `Any`, the lack of bridging here was inconvenient but not likely to cause bugs since Swift provided a compile-time error when an `Int8` was passed in an `AnyObject` context. Now that these imported function signatures are annotated `Any`, it is very easy to accidentally pass an opaque `Int8` into them. It seems utterly inconsistent to not bridge these other numeric types. It would be unfortunate if we kept it this way simply due to historic reasons.

I'm less qualified to talk about the `NSValue` bridging, but in my precursory thoughts it does seem like a decent idea. It seems like it would make the most sense to bridge all `objc_boxable`, but it's not immediately apparent to me that this won't clash with other custom bridging behavior we might want to give certain types in the future.

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes. Though it's clear that `Int8` isn't bridged to `NSNumber` when you write `Int8(x) as NSNumber` (since you get a compile-time error), it is not always quite this apparent. For example, when casting from `Any` to a numeric type, you must force cast with `as!`. Because of this, it is easy to write `num as! Int8` and not realize that, if `num` is an `NSNumber` this code will not compile. Given that `Int` does bridge from `NSNumber`, a reasonable Swift programmer might easily make this mistake.

In a framework I work on, we had a crash in our API when users used `Int8` and friends in as the generic argument of a function. We tested it on `Int`, `Float`, and a whole bunch of other types, but overlooked the lack of numeric bridging for some of these types leading to user crashes. In order to work around this bug, we had to define a `CustomObjectiveCBridgeable` protocol that defines these bridges, and explicitly call a custom bridging function whenever we get a value from Objective-C or pass a value to Objective-C from Swift. We're still discovering bugs in our codebase due to this issue. It's extremely easy to overlook a place that such a conversion is necessary when you provide a dynamic framework.

* Does this proposal fit well with the feel and direction of Swift?

Definitely. In my understanding, Objective-C interop is a major feature of Swift. The Swift team has done a fantastic job improving this since the first release of Swift, and this seems like a logical, incremental step in the same direction.

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I'm not familiar with other languages with such comprehensive bridging features as Swift. That said, this feature is nearly identical to the already-existing `Int` to `NSNumber` bridging feature present in Swift. Like I said before, it doesn't seem so much like an enhancement as it does a bug fix.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I've spent a significant number of hours dealings with issues causes by the lack of bridging here. I've discussed this problem and workarounds with other engineers, and I've filed bug reports related to these issues.

···

I'm really excited about this proposal, so big thanks for those who've spent time on it!
Jaden Geller

On Sep 1, 2016, at 4:58 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0139 "Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue" begins now and runs through September 7, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md
Reply text

Other replies
<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager

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


(Karl) #4

I know the review is over, but I just wanted to chime in with something: does this extend to types which are RawRepresentable as numeric types, too?

For example, Cocoa and UIKit have several option-set types which must be placed in dictionaries. Just now I tried to use UIFontDescriptorSymbolicTraits and it crashed at runtime (radar://28244679 <radar://28244679>).

I consider the current behaviour extremely surprising and definitely a bug.

Karl

···

On 2 Sep 2016, at 01:58, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of SE-0139 "Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue" begins now and runs through September 7, 2016. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md
Reply text

Other replies
<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug Gregor

Review Manager

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


(TJ Usiyan) #5

+1
I like this especially considering that 64 bit iOS has led to more boxing
to `NSNumber` for convenience

···

On Fri, Sep 2, 2016 at 1:23 PM, Scott James Remnant via swift-evolution < swift-evolution@swift.org> wrote:

:+1:

Makes ObjC APIs even easier to work with, without any cost to working with
Swift APIs

On Sep 1, 2016, at 4:58 PM, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The review of SE-0139 "Bridge Numeric Types to NSNumber and Cocoa Structs
to NSValue" begins now and runs through September 7, 2016. The proposal is
available here:

https://github.com/apple/swift-evolution/blob/master/
proposals/0139-bridge-nsnumber-and-nsvalue.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/
proposals/0139-bridge-nsnumber-and-nsvalue.md

Reply text

Other replies

<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1>What
goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

   - What is your evaluation of the proposal?
   - Is the problem being addressed significant enough to warrant a
   change to Swift?
   - Does this proposal fit well with the feel and direction of Swift?
   - If you have used other languages or libraries with a similar
   feature, how do you feel that this proposal compares to those?
   - How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug Gregor

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

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


(Joe Groff) #6

No, that would require separate consideration. It does make sense to me for NS_ENUMs and NS_OPTIONS types from Cocoa to bridge this way, though.

-Joe

···

On Sep 10, 2016, at 7:52 PM, Karl via swift-evolution <swift-evolution@swift.org> wrote:

I know the review is over, but I just wanted to chime in with something: does this extend to types which are RawRepresentable as numeric types, too?

For example, Cocoa and UIKit have several option-set types which must be placed in dictionaries. Just now I tried to use UIFontDescriptorSymbolicTraits and it crashed at runtime (radar://28244679).

I consider the current behaviour extremely surprising and definitely a bug.