Followup after in-the-field feedback for SE-0170


(Philippe Hausler) #1

After implementing the proposal https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md we have gotten some initial feedback.

It seems that there is definitely a fair amount of confusion and heartache for dealing with Float and Double values being bridged.

Specifically the cases like:

NSNumber(value 0.1) as? Float

which with the current implementation will return nil since the Double value 0.1 cannot be represented exactly as a Float.

It seems like the overwhelming majority of users know full well that Float will result in a loss of precision (hence why they chose that type over Double). This means that the floating point bridges for Double, Float, and CGFloat should not be the pedantic “exactly” cases but instead infer the conversion intent of a lax/approximated version.

So in short: for the betterment of the API ergonomics, the floating point types as destinations will be pulled back to their initial Swift 3 behavior.

Additionally to aide appropriate migration to the appropriate truncating/exactly initializers the un-labeled, deprecated in Swift 4, plain init methods to the numeric types with an NSNumber will now be annotated with the suggested replacements.

Thanks for your time and feedback,
Philippe Hausler


(Dave Abrahams) #2

After implementing the proposal
https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md>
we have gotten some initial feedback.

It seems that there is definitely a fair amount of confusion and heartache for dealing with Float
and Double values being bridged.

Specifically the cases like:

NSNumber(value 0.1) as? Float

which with the current implementation will return nil since the Double value 0.1 cannot be
represented exactly as a Float.

It seems like the overwhelming majority of users know full well that
Float will result in a loss of precision (hence why they chose that
type over Double). This means that the floating point bridges for
Double, Float, and CGFloat should not be the pedantic “exactly” cases
but instead infer the conversion intent of a lax/approximated version.

+1

So in short: for the betterment of the API ergonomics, the floating
point types as destinations will be pulled back to their initial Swift
3 behavior.

Additionally to aide appropriate migration to the appropriate
truncating/exactly initializers the un-labeled, deprecated in Swift 4,
plain init methods to the numeric types with an NSNumber will now be
annotated with the suggested replacements.

Sorry, I don't quite understand what that last paragraph implies. Could
you describe what will be deprecated and what will be suggested instead?

···

on Wed Jun 14 2017, Philippe Hausler <swift-evolution@swift.org> wrote:

--
-Dave


(Xiaodi Wu) #3

In SE-0170, it states: "It is worth noting that `is` should follow the same
logic as `as?`." For clarity, does rolling back to the initial Swift 3
behavior mean that `NSNumber(value: 0.1) is Float == true`?

···

On Wed, Jun 14, 2017 at 3:13 PM, Philippe Hausler via swift-evolution < swift-evolution@swift.org> wrote:

After implementing the proposal https://github.com/apple/
swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md we have
gotten some initial feedback.

It seems that there is definitely a fair amount of confusion and heartache
for dealing with Float and Double values being bridged.

Specifically the cases like:

NSNumber(value 0.1) as? Float

which with the current implementation will return nil since the Double
value 0.1 cannot be represented exactly as a Float.

It seems like the overwhelming majority of users know full well that Float
will result in a loss of precision (hence why they chose that type over
Double). This means that the floating point bridges for Double, Float, and
CGFloat should not be the pedantic “exactly” cases but instead infer the
conversion intent of a lax/approximated version.

So in short: for the betterment of the API ergonomics, the floating point
types as destinations will be pulled back to their initial Swift 3 behavior.

Additionally to aide appropriate migration to the appropriate
truncating/exactly initializers the un-labeled, deprecated in Swift 4,
plain init methods to the numeric types with an NSNumber will now be
annotated with the suggested replacements.

Thanks for your time and feedback,
Philippe Hausler

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


(Philippe Hausler) #4

is and as are implemented in the compiler to call the same method

···

Sent from my iPhone

On Jun 14, 2017, at 1:38 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

In SE-0170, it states: "It is worth noting that `is` should follow the same logic as `as?`." For clarity, does rolling back to the initial Swift 3 behavior mean that `NSNumber(value: 0.1) is Float == true`?

On Wed, Jun 14, 2017 at 3:13 PM, Philippe Hausler via swift-evolution <swift-evolution@swift.org> wrote:
After implementing the proposal https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md we have gotten some initial feedback.

It seems that there is definitely a fair amount of confusion and heartache for dealing with Float and Double values being bridged.

Specifically the cases like:

NSNumber(value 0.1) as? Float

which with the current implementation will return nil since the Double value 0.1 cannot be represented exactly as a Float.

It seems like the overwhelming majority of users know full well that Float will result in a loss of precision (hence why they chose that type over Double). This means that the floating point bridges for Double, Float, and CGFloat should not be the pedantic “exactly” cases but instead infer the conversion intent of a lax/approximated version.

So in short: for the betterment of the API ergonomics, the floating point types as destinations will be pulled back to their initial Swift 3 behavior.

Additionally to aide appropriate migration to the appropriate truncating/exactly initializers the un-labeled, deprecated in Swift 4, plain init methods to the numeric types with an NSNumber will now be annotated with the suggested replacements.

Thanks for your time and feedback,
Philippe Hausler

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


(Philippe Hausler) #5

After implementing the proposal
https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md>
we have gotten some initial feedback.

It seems that there is definitely a fair amount of confusion and heartache for dealing with Float
and Double values being bridged.

Specifically the cases like:

NSNumber(value 0.1) as? Float

which with the current implementation will return nil since the Double value 0.1 cannot be
represented exactly as a Float.

It seems like the overwhelming majority of users know full well that
Float will result in a loss of precision (hence why they chose that
type over Double). This means that the floating point bridges for
Double, Float, and CGFloat should not be the pedantic “exactly” cases
but instead infer the conversion intent of a lax/approximated version.

+1

So in short: for the betterment of the API ergonomics, the floating
point types as destinations will be pulled back to their initial Swift
3 behavior.

Additionally to aide appropriate migration to the appropriate
truncating/exactly initializers the un-labeled, deprecated in Swift 4,
plain init methods to the numeric types with an NSNumber will now be
annotated with the suggested replacements.

Sorry, I don't quite understand what that last paragraph implies. Could
you describe what will be deprecated and what will be suggested instead?

https://github.com/phausler/swift/commit/62218c85b6c494c4054ec9774dd6ce095a5d0fa4

So this is just an annotation of renaming to the init(truncating:)

···

On Jun 14, 2017, at 1:47 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Jun 14 2017, Philippe Hausler <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

--
-Dave

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


(Jordan Rose) #6

How about cases where the value is a double that's greater than Float.greatestFiniteMagnitude? Should/Will that produce 'nil' or Float.infinity?

Jordan

···

On Jun 14, 2017, at 13:59, Philippe Hausler via swift-evolution <swift-evolution@swift.org> wrote:

On Jun 14, 2017, at 1:47 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

on Wed Jun 14 2017, Philippe Hausler <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

After implementing the proposal
https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md>
we have gotten some initial feedback.

It seems that there is definitely a fair amount of confusion and heartache for dealing with Float
and Double values being bridged.

Specifically the cases like:

NSNumber(value 0.1) as? Float

which with the current implementation will return nil since the Double value 0.1 cannot be
represented exactly as a Float.

It seems like the overwhelming majority of users know full well that
Float will result in a loss of precision (hence why they chose that
type over Double). This means that the floating point bridges for
Double, Float, and CGFloat should not be the pedantic “exactly” cases
but instead infer the conversion intent of a lax/approximated version.

+1

So in short: for the betterment of the API ergonomics, the floating
point types as destinations will be pulled back to their initial Swift
3 behavior.

Additionally to aide appropriate migration to the appropriate
truncating/exactly initializers the un-labeled, deprecated in Swift 4,
plain init methods to the numeric types with an NSNumber will now be
annotated with the suggested replacements.

Sorry, I don't quite understand what that last paragraph implies. Could
you describe what will be deprecated and what will be suggested instead?

https://github.com/phausler/swift/commit/62218c85b6c494c4054ec9774dd6ce095a5d0fa4

So this is just an annotation of renaming to the init(truncating:)


(Itai Ferber) #7

Those cases will produce `nil`. "Should" is a matter of expectation, but I think that it’s reasonable behavior since it feels truer to the intent the `exactly:` methods.

···

On 16 Jun 2017, at 16:23, Jordan Rose via swift-evolution wrote:

> On Jun 14, 2017, at 13:59, Philippe Hausler via swift-evolution > <swift-evolution@swift.org> wrote:

On Jun 14, 2017, at 1:47 PM, Dave Abrahams via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >>> wrote:

on Wed Jun 14 2017, Philippe Hausler <swift-evolution@swift.org >>> <mailto:swift-evolution@swift.org>> wrote:

After implementing the proposal
https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
<https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md>
we have gotten some initial feedback.

It seems that there is definitely a fair amount of confusion and heartache for dealing with Float
and Double values being bridged.

Specifically the cases like:

NSNumber(value 0.1) as? Float

which with the current implementation will return nil since the Double value 0.1 cannot be
represented exactly as a Float.

It seems like the overwhelming majority of users know full well that
Float will result in a loss of precision (hence why they chose that
type over Double). This means that the floating point bridges for
Double, Float, and CGFloat should not be the pedantic “exactly” cases
but instead infer the conversion intent of a lax/approximated version.

+1

So in short: for the betterment of the API ergonomics, the floating
point types as destinations will be pulled back to their initial Swift
3 behavior.

Additionally to aide appropriate migration to the appropriate
truncating/exactly initializers the un-labeled, deprecated in Swift 4,
plain init methods to the numeric types with an NSNumber will now be
annotated with the suggested replacements.

Sorry, I don't quite understand what that last paragraph implies. Could
you describe what will be deprecated and what will be suggested instead?

https://github.com/phausler/swift/commit/62218c85b6c494c4054ec9774dd6ce095a5d0fa4

So this is just an annotation of renaming to the init(truncating:)

How about cases where the value is a double that's greater than Float.greatestFiniteMagnitude? Should/Will that produce 'nil' or Float.infinity?

Jordan

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