Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

Provided that T is one of the supported types yes that does hold true (and is 
in the unit tests I have on the pending commit)

Sent from my iPhone

> On Apr 20, 2017, at 11:29 AM, Martin R  wrote:
> 
> So is it correct to say that for all types T which NSNumber can hold (Double, 
> Float, Int, UInt, ... )
> 
> T(exactly: someNSNumber)
> 
> will succeed if and only if
> 
> NSNumber(value: T(truncating: someNSNumber)) == someNSNumber
> 
> holds? 
> 
>>> On 20. Apr 2017, at 18:10, Philippe Hausler  wrote:
>>> 
>>> 
>>> On Apr 19, 2017, at 6:09 PM, Xiaodi Wu  wrote:
>>> 
>>> 
>>> 
>>> On Wed, Apr 19, 2017 at 6:35 PM, Philippe Hausler  
>>> wrote:
 
 
> On Apr 19, 2017, at 16:17, Xiaodi Wu  wrote:
> 
>> On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler  
>> wrote:
>> 
>>> On Apr 19, 2017, at 3:23 PM, Xiaodi Wu  wrote:
>>> 
>>> On Wed, Apr 19, 2017 at 3:19 PM, Martin R  wrote:
> On 19. Apr 2017, at 01:48, Xiaodi Wu  wrote:
> 
> So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I 
> would expect NSNumber to behave similarly (a notion with which Martin 
> disagrees, I guess). I don't see a test that shows whether NSNumber 
> behaves or does not behave in that way.
 
 At present they behave differently: 
 
 print(Float(exactly: Double.pi) as Any)
 // nil
 print(Float(exactly: NSNumber(value: Double.pi)) as Any)
 // Optional(3.14159274)
 
 I realize that identical behavior would be logical and least 
 surprising. My only concern was about cases like
 
 let num = ... // some NSNumber from a JSON deserialization
 let fval = Float(exactly: num)
 
 where one cannot know how the number is represented internally and 
 what precision it needs. But then one could use the truncating 
 conversion or `.floatValue` instead.
>>> 
>>> JSON numbers are double-precision floating point, unless I'm 
>>> misunderstanding something. If someone writes `Float(exactly: 
>>> valueParsedFromJSON)`, surely, that can only mean that they *really, 
>>> really* prefer nil over an imprecise value. I can see no other reason 
>>> to insist on using both Float and .init(exactly:).
>> 
>> JSON does not claim 32 or 64 bit floating point, or for that matter 128 
>> or infinite bit floating point :(
> 
> 
> Oops, you're right. I see they've wanted to future-proof this. That said, 
> RFC 7159 *does* say:
> 
>> This specification allows implementations to set limits on the range
>> and precision of numbers accepted.  Since software that implements
>> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
>> generally available and widely used, good interoperability can be
>> achieved by implementations that expect no more precision or range
>> than these provide, in the sense that implementations will
>> approximate JSON numbers within the expected precision.
> 
> 
> So JSON doesn't set limits on how numbers are represented, but JSON 
> implementations are permitted to (and I'd imagine that all in fact do). A 
> user of a JSON deserialization library can rightly expect to know the 
> numeric limits of that implementation; for the purposes of bridging 
> NSNumber, if the answer is that the implementation parses JSON numbers as 
> double-precision values, Double(exactly:) would be the right choice; 
> otherwise, if it's 80-bit values, then Float80(exactly:) would be the 
> right choice, etc.
> 
 
 Float80 is not compatible with NSNumber; and is well out of scope for this 
 proposal.
>>> 
>>> OK, so Double is the largest floating point type compatible with NSNumber? 
>>> It stands to reason that any Swift JSON implementation that uses NSNumber 
>>> for parsed floating point values would at most have that much range and 
>>> precision, right?
>> 
>> For JSONSerialization (which I am most familiar with and ships with 
>> Foundation); it can emit both NSNumbers and NSDecimalNumber. A rough 
>> approximation of the behavior: if it can store the value in an integer type 
>> it stores it as such in a NSNumber (iirc up to UINT64_MAX) and then if it 
>> has a decimal point it will attempt to parse as a double but if that is not 
>> enough storage it will store the best possible value into NSDecimalNumber. 
>> 
>> So NSNumber itself (excluding subclasses) can only store up to a 64 bit 
>> value. 
>> 
>>> 
>>> If so, then every floating point value parsed by any such Swift JSON 
>>> implementation would be exactly representable as a Double: regardless of 
>>> whether 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Martin R via swift-evolution]

So is it correct to say that for all types T which NSNumber can hold (Double, 
Float, Int, UInt, ... )

T(exactly: someNSNumber)

will succeed if and only if

NSNumber(value: T(truncating: someNSNumber)) == someNSNumber

holds? 

> On 20. Apr 2017, at 18:10, Philippe Hausler  wrote:
> 
>> 
>> On Apr 19, 2017, at 6:09 PM, Xiaodi Wu > > wrote:
>> 
>> 
>> 
>> On Wed, Apr 19, 2017 at 6:35 PM, Philippe Hausler > > wrote:
>> 
>> 
>>> On Apr 19, 2017, at 16:17, Xiaodi Wu >> > wrote:
>>> 
>>> On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler >> > wrote:
>>> 
 On Apr 19, 2017, at 3:23 PM, Xiaodi Wu > wrote:
 
 On Wed, Apr 19, 2017 at 3:19 PM, Martin R > wrote:
> On 19. Apr 2017, at 01:48, Xiaodi Wu  > wrote:
> 
> So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would 
> expect NSNumber to behave similarly (a notion with which Martin 
> disagrees, I guess). I don't see a test that shows whether NSNumber 
> behaves or does not behave in that way.
 
 At present they behave differently: 
 
 print(Float(exactly: Double.pi) as Any)
 // nil
 print(Float(exactly: NSNumber(value: Double.pi)) as Any)
 // Optional(3.14159274)
 
 I realize that identical behavior would be logical and least surprising. 
 My only concern was about cases like
 
 let num = ... // some NSNumber from a JSON deserialization
 let fval = Float(exactly: num)
 
 where one cannot know how the number is represented internally and what 
 precision it needs. But then one could use the truncating conversion or 
 `.floatValue` instead.
 
 JSON numbers are double-precision floating point, unless I'm 
 misunderstanding something. If someone writes `Float(exactly: 
 valueParsedFromJSON)`, surely, that can only mean that they *really, 
 really* prefer nil over an imprecise value. I can see no other reason to 
 insist on using both Float and .init(exactly:).
>>> 
>>> JSON does not claim 32 or 64 bit floating point, or for that matter 128 or 
>>> infinite bit floating point :(
>>> 
>>> 
>>> Oops, you're right. I see they've wanted to future-proof this. That said, 
>>> RFC 7159 *does* say:
>>> 
>>> This specification allows implementations to set limits on the range
>>> and precision of numbers accepted.  Since software that implements
>>> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
>>> generally available and widely used, good interoperability can be
>>> achieved by implementations that expect no more precision or range
>>> than these provide, in the sense that implementations will
>>> approximate JSON numbers within the expected precision.
>>> 
>>> So JSON doesn't set limits on how numbers are represented, but JSON 
>>> implementations are permitted to (and I'd imagine that all in fact do). A 
>>> user of a JSON deserialization library can rightly expect to know the 
>>> numeric limits of that implementation; for the purposes of bridging 
>>> NSNumber, if the answer is that the implementation parses JSON numbers as 
>>> double-precision values, Double(exactly:) would be the right choice; 
>>> otherwise, if it's 80-bit values, then Float80(exactly:) would be the right 
>>> choice, etc.
>>> 
>> 
>> Float80 is not compatible with NSNumber; and is well out of scope for this 
>> proposal.
>> 
>> OK, so Double is the largest floating point type compatible with NSNumber? 
>> It stands to reason that any Swift JSON implementation that uses NSNumber 
>> for parsed floating point values would at most have that much range and 
>> precision, right?
> 
> For JSONSerialization (which I am most familiar with and ships with 
> Foundation); it can emit both NSNumbers and NSDecimalNumber. A rough 
> approximation of the behavior: if it can store the value in an integer type 
> it stores it as such in a NSNumber (iirc up to UINT64_MAX) and then if it has 
> a decimal point it will attempt to parse as a double but if that is not 
> enough storage it will store the best possible value into NSDecimalNumber. 
> 
> So NSNumber itself (excluding subclasses) can only store up to a 64 bit 
> value. 
> 
>> 
>> If so, then every floating point value parsed by any such Swift JSON 
>> implementation would be exactly representable as a Double: regardless of 
>> whether that specific implementation uses Float or Double under the hood, 
>> every Float can be represented exactly as a Double. If a user is trying to 
>> bridge such a NSNumber instance specifically to *Float* instead of Double, 
>> and they are asking for an 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Xiaodi Wu via swift-evolution]

Right. I think we're in vigorous agreement.


On Thu, Apr 20, 2017 at 11:11 Philippe Hausler  wrote:

> On Apr 19, 2017, at 6:09 PM, Xiaodi Wu  wrote:
>
>
>
> On Wed, Apr 19, 2017 at 6:35 PM, Philippe Hausler 
> wrote:
>
>>
>>
>> On Apr 19, 2017, at 16:17, Xiaodi Wu  wrote:
>>
>> On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler 
>> wrote:
>>
>>>
>>> On Apr 19, 2017, at 3:23 PM, Xiaodi Wu  wrote:
>>>
>>> On Wed, Apr 19, 2017 at 3:19 PM, Martin R  wrote:
>>>
 On 19. Apr 2017, at 01:48, Xiaodi Wu  wrote:

 So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I
 would expect NSNumber to behave similarly (a notion with which Martin
 disagrees, I guess). I don't see a test that shows whether NSNumber behaves
 or does not behave in that way.


 At present they behave differently:

 print(Float(exactly: Double.pi) as Any)
 // nil
 print(Float(exactly: NSNumber(value: Double.pi)) as Any)
 // Optional(3.14159274)

 I realize that identical behavior would be logical and least
 surprising. My only concern was about cases like

 let num = ... // some NSNumber from a JSON deserialization
 let fval = Float(exactly: num)

 where one cannot know how the number is represented internally and what
 precision it needs. But then one could use the truncating conversion or
 `.floatValue` instead.

>>>
>>> JSON numbers are double-precision floating point, unless I'm
>>> misunderstanding something. If someone writes `Float(exactly:
>>> valueParsedFromJSON)`, surely, that can only mean that they *really,
>>> really* prefer nil over an imprecise value. I can see no other reason to
>>> insist on using both Float and .init(exactly:).
>>>
>>>
>>> JSON does not claim 32 or 64 bit floating point, or for that matter 128
>>> or infinite bit floating point :(
>>>
>>
>>
>> Oops, you're right. I see they've wanted to future-proof this. That said,
>> RFC 7159 *does* say:
>>
>> This specification allows implementations to set limits on the range
>>
>> and precision of numbers accepted.  Since software that implements
>>
>> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
>>> generally available and widely used, good interoperability can be
>>> achieved by implementations that expect no more precision or range
>>> than these provide, in the sense that implementations will
>>> approximate JSON numbers within the expected precision.
>>
>>
>> So JSON doesn't set limits on how numbers are represented, but JSON
>> implementations are permitted to (and I'd imagine that all in fact do). A
>> user of a JSON deserialization library can rightly expect to know the
>> numeric limits of that implementation; for the purposes of bridging
>> NSNumber, if the answer is that the implementation parses JSON numbers as
>> double-precision values, Double(exactly:) would be the right choice;
>> otherwise, if it's 80-bit values, then Float80(exactly:) would be the right
>> choice, etc.
>>
>>
>> Float80 is not compatible with NSNumber; and is well out of scope for
>> this proposal.
>>
>
> OK, so Double is the largest floating point type compatible with NSNumber?
> It stands to reason that any Swift JSON implementation that uses NSNumber
> for parsed floating point values would at most have that much range and
> precision, right?
>
>
> For JSONSerialization (which I am most familiar with and ships with
> Foundation); it can emit both NSNumbers and NSDecimalNumber. A rough
> approximation of the behavior: if it can store the value in an integer type
> it stores it as such in a NSNumber (iirc up to UINT64_MAX) and then if it
> has a decimal point it will attempt to parse as a double but if that is not
> enough storage it will store the best possible value into NSDecimalNumber.
>
> So NSNumber itself (excluding subclasses) can only store up to a 64 bit
> value.
>
>
> If so, then every floating point value parsed by any such Swift JSON
> implementation would be exactly representable as a Double: regardless of
> whether that specific implementation uses Float or Double under the hood,
> every Float can be represented exactly as a Double. If a user is trying to
> bridge such a NSNumber instance specifically to *Float* instead of Double,
> and they are asking for an exact value, there's no a priori reason to think
> that this user would be more likely to care only about the range and not
> the precision, or vice versa. Which is to say, I don't think you'll get too
> many bug reports :)
>
>
> In my mind there are two considerations here; balance against the surprise
> from new developers learning their first programming language versus
> consistency. In the end even if I believe the behavior is sub-par I would
> rather it be consistent. Primarily consistency is easier 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 19, 2017, at 6:09 PM, Xiaodi Wu  wrote:
> 
> 
> 
> On Wed, Apr 19, 2017 at 6:35 PM, Philippe Hausler  > wrote:
> 
> 
>> On Apr 19, 2017, at 16:17, Xiaodi Wu > > wrote:
>> 
>> On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler > > wrote:
>> 
>>> On Apr 19, 2017, at 3:23 PM, Xiaodi Wu >> > wrote:
>>> 
>>> On Wed, Apr 19, 2017 at 3:19 PM, Martin R >> > wrote:
 On 19. Apr 2017, at 01:48, Xiaodi Wu > wrote:
 
 So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would 
 expect NSNumber to behave similarly (a notion with which Martin disagrees, 
 I guess). I don't see a test that shows whether NSNumber behaves or does 
 not behave in that way.
>>> 
>>> At present they behave differently: 
>>> 
>>> print(Float(exactly: Double.pi) as Any)
>>> // nil
>>> print(Float(exactly: NSNumber(value: Double.pi)) as Any)
>>> // Optional(3.14159274)
>>> 
>>> I realize that identical behavior would be logical and least surprising. My 
>>> only concern was about cases like
>>> 
>>> let num = ... // some NSNumber from a JSON deserialization
>>> let fval = Float(exactly: num)
>>> 
>>> where one cannot know how the number is represented internally and what 
>>> precision it needs. But then one could use the truncating conversion or 
>>> `.floatValue` instead.
>>> 
>>> JSON numbers are double-precision floating point, unless I'm 
>>> misunderstanding something. If someone writes `Float(exactly: 
>>> valueParsedFromJSON)`, surely, that can only mean that they *really, 
>>> really* prefer nil over an imprecise value. I can see no other reason to 
>>> insist on using both Float and .init(exactly:).
>> 
>> JSON does not claim 32 or 64 bit floating point, or for that matter 128 or 
>> infinite bit floating point :(
>> 
>> 
>> Oops, you're right. I see they've wanted to future-proof this. That said, 
>> RFC 7159 *does* say:
>> 
>> This specification allows implementations to set limits on the range
>> and precision of numbers accepted.  Since software that implements
>> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
>> generally available and widely used, good interoperability can be
>> achieved by implementations that expect no more precision or range
>> than these provide, in the sense that implementations will
>> approximate JSON numbers within the expected precision.
>> 
>> So JSON doesn't set limits on how numbers are represented, but JSON 
>> implementations are permitted to (and I'd imagine that all in fact do). A 
>> user of a JSON deserialization library can rightly expect to know the 
>> numeric limits of that implementation; for the purposes of bridging 
>> NSNumber, if the answer is that the implementation parses JSON numbers as 
>> double-precision values, Double(exactly:) would be the right choice; 
>> otherwise, if it's 80-bit values, then Float80(exactly:) would be the right 
>> choice, etc.
>> 
> 
> Float80 is not compatible with NSNumber; and is well out of scope for this 
> proposal.
> 
> OK, so Double is the largest floating point type compatible with NSNumber? It 
> stands to reason that any Swift JSON implementation that uses NSNumber for 
> parsed floating point values would at most have that much range and 
> precision, right?

For JSONSerialization (which I am most familiar with and ships with 
Foundation); it can emit both NSNumbers and NSDecimalNumber. A rough 
approximation of the behavior: if it can store the value in an integer type it 
stores it as such in a NSNumber (iirc up to UINT64_MAX) and then if it has a 
decimal point it will attempt to parse as a double but if that is not enough 
storage it will store the best possible value into NSDecimalNumber. 

So NSNumber itself (excluding subclasses) can only store up to a 64 bit value. 

> 
> If so, then every floating point value parsed by any such Swift JSON 
> implementation would be exactly representable as a Double: regardless of 
> whether that specific implementation uses Float or Double under the hood, 
> every Float can be represented exactly as a Double. If a user is trying to 
> bridge such a NSNumber instance specifically to *Float* instead of Double, 
> and they are asking for an exact value, there's no a priori reason to think 
> that this user would be more likely to care only about the range and not the 
> precision, or vice versa. Which is to say, I don't think you'll get too many 
> bug reports :)

In my mind there are two considerations here; balance against the surprise from 
new developers learning their first programming language versus consistency. In 
the end even if I believe the behavior is sub-par I would rather it be 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Xiaodi Wu via swift-evolution]

On Wed, Apr 19, 2017 at 6:35 PM, Philippe Hausler 
wrote:

>
>
> On Apr 19, 2017, at 16:17, Xiaodi Wu  wrote:
>
> On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler  w
> rote:
>
>>
>> On Apr 19, 2017, at 3:23 PM, Xiaodi Wu  wrote:
>>
>> On Wed, Apr 19, 2017 at 3:19 PM, Martin R  wrote:
>>
>>> On 19. Apr 2017, at 01:48, Xiaodi Wu  wrote:
>>>
>>> So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would
>>> expect NSNumber to behave similarly (a notion with which Martin disagrees,
>>> I guess). I don't see a test that shows whether NSNumber behaves or does
>>> not behave in that way.
>>>
>>>
>>> At present they behave differently:
>>>
>>> print(Float(exactly: Double.pi) as Any)
>>> // nil
>>> print(Float(exactly: NSNumber(value: Double.pi)) as Any)
>>> // Optional(3.14159274)
>>>
>>> I realize that identical behavior would be logical and least surprising.
>>> My only concern was about cases like
>>>
>>> let num = ... // some NSNumber from a JSON deserialization
>>> let fval = Float(exactly: num)
>>>
>>> where one cannot know how the number is represented internally and what
>>> precision it needs. But then one could use the truncating conversion or
>>> `.floatValue` instead.
>>>
>>
>> JSON numbers are double-precision floating point, unless I'm
>> misunderstanding something. If someone writes `Float(exactly:
>> valueParsedFromJSON)`, surely, that can only mean that they *really,
>> really* prefer nil over an imprecise value. I can see no other reason to
>> insist on using both Float and .init(exactly:).
>>
>>
>> JSON does not claim 32 or 64 bit floating point, or for that matter 128
>> or infinite bit floating point :(
>>
>
>
> Oops, you're right. I see they've wanted to future-proof this. That said,
> RFC 7159 *does* say:
>
> This specification allows implementations to set limits on the range
>
> and precision of numbers accepted.  Since software that implements
>
> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
>> generally available and widely used, good interoperability can be
>> achieved by implementations that expect no more precision or range
>> than these provide, in the sense that implementations will
>> approximate JSON numbers within the expected precision.
>
>
> So JSON doesn't set limits on how numbers are represented, but JSON
> implementations are permitted to (and I'd imagine that all in fact do). A
> user of a JSON deserialization library can rightly expect to know the
> numeric limits of that implementation; for the purposes of bridging
> NSNumber, if the answer is that the implementation parses JSON numbers as
> double-precision values, Double(exactly:) would be the right choice;
> otherwise, if it's 80-bit values, then Float80(exactly:) would be the right
> choice, etc.
>
>
> Float80 is not compatible with NSNumber; and is well out of scope for this
> proposal.
>

OK, so Double is the largest floating point type compatible with NSNumber?
It stands to reason that any Swift JSON implementation that uses NSNumber
for parsed floating point values would at most have that much range and
precision, right?

If so, then every floating point value parsed by any such Swift JSON
implementation would be exactly representable as a Double: regardless of
whether that specific implementation uses Float or Double under the hood,
every Float can be represented exactly as a Double. If a user is trying to
bridge such a NSNumber instance specifically to *Float* instead of Double,
and they are asking for an exact value, there's no a priori reason to think
that this user would be more likely to care only about the range and not
the precision, or vice versa. Which is to say, I don't think you'll get too
many bug reports :)


> After thinking about it more; it seems reasonable to restrict it to the
>> behavior of Float(exactly: Double(…)). I am certain this will probably in
>> the end cause more bugs for me to have to address and mark as “behaves
>> correctly” and confuse a few new developers - but in the end they chose
>> Swift and the consistent story would be the current behavior of
>> Float(exactly: Double).
>>
>>
>>
>>>
>>> On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler 
>>> wrote:
>>>

 On Apr 18, 2017, at 9:22 AM, Stephen Canon  wrote:


 On Apr 18, 2017, at 12:17 PM, Joe Groff  wrote:


 On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution <
 swift-evolution@swift.org> wrote:

 It seems Float.init(exactly: NSNumber) has not been updated to behave
 similarly?

 I would have to say, I would naively expect "exactly" to behave exactly
 as it says, exactly. I don't think it should be a synonym for
 Float(Double(exactly:)).
 On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution <
 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 19, 2017, at 16:17, Xiaodi Wu  wrote:
> 
> On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler  > wrote:
> 
>> On Apr 19, 2017, at 3:23 PM, Xiaodi Wu > > wrote:
>> 
>> On Wed, Apr 19, 2017 at 3:19 PM, Martin R > > wrote:
>>> On 19. Apr 2017, at 01:48, Xiaodi Wu >> > wrote:
>>> 
>>> So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would 
>>> expect NSNumber to behave similarly (a notion with which Martin disagrees, 
>>> I guess). I don't see a test that shows whether NSNumber behaves or does 
>>> not behave in that way.
>> 
>> At present they behave differently: 
>> 
>> print(Float(exactly: Double.pi) as Any)
>> // nil
>> print(Float(exactly: NSNumber(value: Double.pi)) as Any)
>> // Optional(3.14159274)
>> 
>> I realize that identical behavior would be logical and least surprising. My 
>> only concern was about cases like
>> 
>> let num = ... // some NSNumber from a JSON deserialization
>> let fval = Float(exactly: num)
>> 
>> where one cannot know how the number is represented internally and what 
>> precision it needs. But then one could use the truncating conversion or 
>> `.floatValue` instead.
>> 
>> JSON numbers are double-precision floating point, unless I'm 
>> misunderstanding something. If someone writes `Float(exactly: 
>> valueParsedFromJSON)`, surely, that can only mean that they *really, really* 
>> prefer nil over an imprecise value. I can see no other reason to insist on 
>> using both Float and .init(exactly:).
> 
> JSON does not claim 32 or 64 bit floating point, or for that matter 128 or 
> infinite bit floating point :(
> 
> 
> Oops, you're right. I see they've wanted to future-proof this. That said, RFC 
> 7159 *does* say:
> 
> This specification allows implementations to set limits on the range
> and precision of numbers accepted.  Since software that implements
> IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
> generally available and widely used, good interoperability can be
> achieved by implementations that expect no more precision or range
> than these provide, in the sense that implementations will
> approximate JSON numbers within the expected precision.
> 
> So JSON doesn't set limits on how numbers are represented, but JSON 
> implementations are permitted to (and I'd imagine that all in fact do). A 
> user of a JSON deserialization library can rightly expect to know the numeric 
> limits of that implementation; for the purposes of bridging NSNumber, if the 
> answer is that the implementation parses JSON numbers as double-precision 
> values, Double(exactly:) would be the right choice; otherwise, if it's 80-bit 
> values, then Float80(exactly:) would be the right choice, etc.
> 

Float80 is not compatible with NSNumber; and is well out of scope for this 
proposal.

> 
> After thinking about it more; it seems reasonable to restrict it to the 
> behavior of Float(exactly: Double(…)). I am certain this will probably in the 
> end cause more bugs for me to have to address and mark as “behaves correctly” 
> and confuse a few new developers - but in the end they chose Swift and the 
> consistent story would be the current behavior of Float(exactly: Double).
> 
>> 
>>> 
>>> 
>>> On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler >> > wrote:
>>> 
 On Apr 18, 2017, at 9:22 AM, Stephen Canon > wrote:
 
> 
> On Apr 18, 2017, at 12:17 PM, Joe Groff  > wrote:
> 
> 
>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> It seems Float.init(exactly: NSNumber) has not been updated to behave 
>> similarly?
>> 
>> I would have to say, I would naively expect "exactly" to behave exactly 
>> as it says, exactly. I don't think it should be a synonym for 
>> Float(Double(exactly:)).
>> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution 
>> > wrote:
>> I posted my branch and fixed up the Double case to account for your 
>> concerns (with a few inspired unit tests to validate)
>> 
>> https://github.com/phausler/swift/tree/safe_nsnumber 
>> 
>> 
>> There is a builtin assumption here though: it does presume that the 
>> swift’s representation of Double and Float are IEEE compliant. However 
>> that is a fairly reasonable assumption in the tests.
> 
>> 
>> 
>> Even with the updated code at 
>> https://github.com/phausler/swift/tree/safe_nsnumber 
>> 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Xiaodi Wu via swift-evolution]

On Wed, Apr 19, 2017 at 6:00 PM, Philippe Hausler 
wrote:

>
> On Apr 19, 2017, at 3:23 PM, Xiaodi Wu  wrote:
>
> On Wed, Apr 19, 2017 at 3:19 PM, Martin R  wrote:
>
>> On 19. Apr 2017, at 01:48, Xiaodi Wu  wrote:
>>
>> So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would
>> expect NSNumber to behave similarly (a notion with which Martin disagrees,
>> I guess). I don't see a test that shows whether NSNumber behaves or does
>> not behave in that way.
>>
>>
>> At present they behave differently:
>>
>> print(Float(exactly: Double.pi) as Any)
>> // nil
>> print(Float(exactly: NSNumber(value: Double.pi)) as Any)
>> // Optional(3.14159274)
>>
>> I realize that identical behavior would be logical and least surprising.
>> My only concern was about cases like
>>
>> let num = ... // some NSNumber from a JSON deserialization
>> let fval = Float(exactly: num)
>>
>> where one cannot know how the number is represented internally and what
>> precision it needs. But then one could use the truncating conversion or
>> `.floatValue` instead.
>>
>
> JSON numbers are double-precision floating point, unless I'm
> misunderstanding something. If someone writes `Float(exactly:
> valueParsedFromJSON)`, surely, that can only mean that they *really,
> really* prefer nil over an imprecise value. I can see no other reason to
> insist on using both Float and .init(exactly:).
>
>
> JSON does not claim 32 or 64 bit floating point, or for that matter 128 or
> infinite bit floating point :(
>


Oops, you're right. I see they've wanted to future-proof this. That said,
RFC 7159 *does* say:

This specification allows implementations to set limits on the range

and precision of numbers accepted.  Since software that implements

IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
> generally available and widely used, good interoperability can be
> achieved by implementations that expect no more precision or range
> than these provide, in the sense that implementations will
> approximate JSON numbers within the expected precision.


So JSON doesn't set limits on how numbers are represented, but JSON
implementations are permitted to (and I'd imagine that all in fact do). A
user of a JSON deserialization library can rightly expect to know the
numeric limits of that implementation; for the purposes of bridging
NSNumber, if the answer is that the implementation parses JSON numbers as
double-precision values, Double(exactly:) would be the right choice;
otherwise, if it's 80-bit values, then Float80(exactly:) would be the right
choice, etc.


After thinking about it more; it seems reasonable to restrict it to the
> behavior of Float(exactly: Double(…)). I am certain this will probably in
> the end cause more bugs for me to have to address and mark as “behaves
> correctly” and confuse a few new developers - but in the end they chose
> Swift and the consistent story would be the current behavior of
> Float(exactly: Double).
>
>
>
>>
>> On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler  w
>> rote:
>>
>>>
>>> On Apr 18, 2017, at 9:22 AM, Stephen Canon  wrote:
>>>
>>>
>>> On Apr 18, 2017, at 12:17 PM, Joe Groff  wrote:
>>>
>>>
>>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> It seems Float.init(exactly: NSNumber) has not been updated to behave
>>> similarly?
>>>
>>> I would have to say, I would naively expect "exactly" to behave exactly
>>> as it says, exactly. I don't think it should be a synonym for
>>> Float(Double(exactly:)).
>>> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> I posted my branch and fixed up the Double case to account for your
>>> concerns (with a few inspired unit tests to validate)
>>>
>>> https://github.com/phausler/swift/tree/safe_nsnumber
>>>
>>> There is a builtin assumption here though: it does presume that the
>>> swift’s representation of Double and Float are IEEE compliant. However that
>>> is a fairly reasonable assumption in the tests.
>>>
>>>
>>>
>>
>> Even with the updated code at https://github.com/phausler
>> /swift/tree/safe_nsnumber
>>
>> print(Double(exactly: NSNumber(value: Int64(901))) as
>>  Any)
>> // Optional(9e+18)
>>
>> still succeeds, however the reason seems to be an error in the
>> `init(exactly value: someIntegerType)` inititializers of Float/Double, I
>> have submitted a bug report: https://bugs.swift.org/browse/SR-4634.
>>
>>
>> (+Steve Canon) What is the behavior of Float.init(exactly: Double)?
>>> NSNumber's behavior would ideally be consistent with that.
>>>
>>>
>>> The implementation is essentially just:
>>>
>>> self.init(other)
>>> guard Double(self) == other else {
>>> return nil
>>> }
>>>
>>> i.e. if the result is not equal to the source when round-tripped 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 19, 2017, at 3:23 PM, Xiaodi Wu  wrote:
> 
> On Wed, Apr 19, 2017 at 3:19 PM, Martin R  > wrote:
>> On 19. Apr 2017, at 01:48, Xiaodi Wu > > wrote:
>> 
>> So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would 
>> expect NSNumber to behave similarly (a notion with which Martin disagrees, I 
>> guess). I don't see a test that shows whether NSNumber behaves or does not 
>> behave in that way.
> 
> At present they behave differently: 
> 
> print(Float(exactly: Double.pi) as Any)
> // nil
> print(Float(exactly: NSNumber(value: Double.pi)) as Any)
> // Optional(3.14159274)
> 
> I realize that identical behavior would be logical and least surprising. My 
> only concern was about cases like
> 
> let num = ... // some NSNumber from a JSON deserialization
> let fval = Float(exactly: num)
> 
> where one cannot know how the number is represented internally and what 
> precision it needs. But then one could use the truncating conversion or 
> `.floatValue` instead.
> 
> JSON numbers are double-precision floating point, unless I'm misunderstanding 
> something. If someone writes `Float(exactly: valueParsedFromJSON)`, surely, 
> that can only mean that they *really, really* prefer nil over an imprecise 
> value. I can see no other reason to insist on using both Float and 
> .init(exactly:).

JSON does not claim 32 or 64 bit floating point, or for that matter 128 or 
infinite bit floating point :(

After thinking about it more; it seems reasonable to restrict it to the 
behavior of Float(exactly: Double(…)). I am certain this will probably in the 
end cause more bugs for me to have to address and mark as “behaves correctly” 
and confuse a few new developers - but in the end they chose Swift and the 
consistent story would be the current behavior of Float(exactly: Double).

> 
>> 
>> 
>> On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler > > wrote:
>> 
>>> On Apr 18, 2017, at 9:22 AM, Stephen Canon >> > wrote:
>>> 
 
 On Apr 18, 2017, at 12:17 PM, Joe Groff > wrote:
 
 
> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> 
> It seems Float.init(exactly: NSNumber) has not been updated to behave 
> similarly?
> 
> I would have to say, I would naively expect "exactly" to behave exactly 
> as it says, exactly. I don't think it should be a synonym for 
> Float(Double(exactly:)).
> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution 
> > wrote:
> I posted my branch and fixed up the Double case to account for your 
> concerns (with a few inspired unit tests to validate)
> 
> https://github.com/phausler/swift/tree/safe_nsnumber 
> 
> 
> There is a builtin assumption here though: it does presume that the 
> swift’s representation of Double and Float are IEEE compliant. However 
> that is a fairly reasonable assumption in the tests.
 
> 
> 
> Even with the updated code at 
> https://github.com/phausler/swift/tree/safe_nsnumber 
> 
> 
> print(Double(exactly: NSNumber(value: Int64(901))) as Any)
> // Optional(9e+18)
> 
> still succeeds, however the reason seems to be an error in the `init(exactly 
> value: someIntegerType)` inititializers of Float/Double, I have submitted a 
> bug report: https://bugs.swift.org/browse/SR-4634 
> .
> 
> 
 (+Steve Canon) What is the behavior of Float.init(exactly: Double)? 
 NSNumber's behavior would ideally be consistent with that.
>>> 
>>> The implementation is essentially just:
>>> 
>>> self.init(other)
>>> guard Double(self) == other else {
>>> return nil
>>> }
>>> 
>>> i.e. if the result is not equal to the source when round-tripped back to 
>>> double (which is always exact), the result is nil.
>>> 
>>> – Steve
>> 
>> Pretty much the same trick inside of CFNumber/NSNumber

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

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Xiaodi Wu via swift-evolution]

On Wed, Apr 19, 2017 at 3:19 PM, Martin R  wrote:

> On 19. Apr 2017, at 01:48, Xiaodi Wu  wrote:
>
> So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would
> expect NSNumber to behave similarly (a notion with which Martin disagrees,
> I guess). I don't see a test that shows whether NSNumber behaves or does
> not behave in that way.
>
>
> At present they behave differently:
>
> print(Float(exactly: Double.pi) as Any)
> // nil
> print(Float(exactly: NSNumber(value: Double.pi)) as Any)
> // Optional(3.14159274)
>
> I realize that identical behavior would be logical and least surprising.
> My only concern was about cases like
>
> let num = ... // some NSNumber from a JSON deserialization
> let fval = Float(exactly: num)
>
> where one cannot know how the number is represented internally and what
> precision it needs. But then one could use the truncating conversion or
> `.floatValue` instead.
>

JSON numbers are double-precision floating point, unless I'm
misunderstanding something. If someone writes `Float(exactly:
valueParsedFromJSON)`, surely, that can only mean that they *really,
really* prefer nil over an imprecise value. I can see no other reason to
insist on using both Float and .init(exactly:).


>
> On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler 
> wrote:
>
>>
>> On Apr 18, 2017, at 9:22 AM, Stephen Canon  wrote:
>>
>>
>> On Apr 18, 2017, at 12:17 PM, Joe Groff  wrote:
>>
>>
>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It seems Float.init(exactly: NSNumber) has not been updated to behave
>> similarly?
>>
>> I would have to say, I would naively expect "exactly" to behave exactly
>> as it says, exactly. I don't think it should be a synonym for
>> Float(Double(exactly:)).
>> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> I posted my branch and fixed up the Double case to account for your
>> concerns (with a few inspired unit tests to validate)
>>
>> https://github.com/phausler/swift/tree/safe_nsnumber
>>
>> There is a builtin assumption here though: it does presume that the
>> swift’s representation of Double and Float are IEEE compliant. However that
>> is a fairly reasonable assumption in the tests.
>>
>>
>>
>
> Even with the updated code at https://github.com/phausler/swift/tree/safe_
> nsnumber
>
> print(Double(exactly: NSNumber(value: Int64(901))) as
> Any)
> // Optional(9e+18)
>
> still succeeds, however the reason seems to be an error in the
> `init(exactly value: someIntegerType)` inititializers of Float/Double, I
> have submitted a bug report: https://bugs.swift.org/browse/SR-4634.
>
>
> (+Steve Canon) What is the behavior of Float.init(exactly: Double)?
>> NSNumber's behavior would ideally be consistent with that.
>>
>>
>> The implementation is essentially just:
>>
>> self.init(other)
>> guard Double(self) == other else {
>> return nil
>> }
>>
>> i.e. if the result is not equal to the source when round-tripped back to
>> double (which is always exact), the result is nil.
>>
>> – Steve
>>
>>
>> Pretty much the same trick inside of CFNumber/NSNumber
>>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Martin R via swift-evolution]

> On 19. Apr 2017, at 01:48, Xiaodi Wu  wrote:
> 
> So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would 
> expect NSNumber to behave similarly (a notion with which Martin disagrees, I 
> guess). I don't see a test that shows whether NSNumber behaves or does not 
> behave in that way.

At present they behave differently: 

print(Float(exactly: Double.pi) as Any)
// nil
print(Float(exactly: NSNumber(value: Double.pi)) as Any)
// Optional(3.14159274)

I realize that identical behavior would be logical and least surprising. My 
only concern was about cases like

let num = ... // some NSNumber from a JSON deserialization
let fval = Float(exactly: num)

where one cannot know how the number is represented internally and what 
precision it needs. But then one could use the truncating conversion or 
`.floatValue` instead.

> 
> 
> On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler  > wrote:
> 
>> On Apr 18, 2017, at 9:22 AM, Stephen Canon > > wrote:
>> 
>>> 
>>> On Apr 18, 2017, at 12:17 PM, Joe Groff >> > wrote:
>>> 
>>> 
 On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution 
 > wrote:
 
 It seems Float.init(exactly: NSNumber) has not been updated to behave 
 similarly?
 
 I would have to say, I would naively expect "exactly" to behave exactly as 
 it says, exactly. I don't think it should be a synonym for 
 Float(Double(exactly:)).
 On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution 
 > wrote:
 I posted my branch and fixed up the Double case to account for your 
 concerns (with a few inspired unit tests to validate)
 
 https://github.com/phausler/swift/tree/safe_nsnumber 
 
 
 There is a builtin assumption here though: it does presume that the 
 swift’s representation of Double and Float are IEEE compliant. However 
 that is a fairly reasonable assumption in the tests.
>>> 


Even with the updated code at 
https://github.com/phausler/swift/tree/safe_nsnumber

print(Double(exactly: NSNumber(value: Int64(901))) as Any)
// Optional(9e+18)

still succeeds, however the reason seems to be an error in the `init(exactly 
value: someIntegerType)` inititializers of Float/Double, I have submitted a bug 
report: https://bugs.swift.org/browse/SR-4634 
.


>>> (+Steve Canon) What is the behavior of Float.init(exactly: Double)? 
>>> NSNumber's behavior would ideally be consistent with that.
>> 
>> The implementation is essentially just:
>> 
>>  self.init(other)
>>  guard Double(self) == other else {
>>  return nil
>>  }
>> 
>> i.e. if the result is not equal to the source when round-tripped back to 
>> double (which is always exact), the result is nil.
>> 
>> – Steve
> 
> Pretty much the same trick inside of CFNumber/NSNumber
> 

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

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Xiaodi Wu via swift-evolution]

So, as I understand it, `Float.init(exactly: Double.pi) == nil`. I would
expect NSNumber to behave similarly (a notion with which Martin disagrees,
I guess). I don't see a test that shows whether NSNumber behaves or does
not behave in that way.


On Tue, Apr 18, 2017 at 11:43 AM, Philippe Hausler 
wrote:

>
> On Apr 18, 2017, at 9:22 AM, Stephen Canon  wrote:
>
>
> On Apr 18, 2017, at 12:17 PM, Joe Groff  wrote:
>
>
> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> It seems Float.init(exactly: NSNumber) has not been updated to behave
> similarly?
>
> I would have to say, I would naively expect "exactly" to behave exactly as
> it says, exactly. I don't think it should be a synonym for
> Float(Double(exactly:)).
> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution <
> swift-evolution@swift.org> wrote:
> I posted my branch and fixed up the Double case to account for your
> concerns (with a few inspired unit tests to validate)
>
> https://github.com/phausler/swift/tree/safe_nsnumber
>
> There is a builtin assumption here though: it does presume that the
> swift’s representation of Double and Float are IEEE compliant. However that
> is a fairly reasonable assumption in the tests.
>
>
> (+Steve Canon) What is the behavior of Float.init(exactly: Double)?
> NSNumber's behavior would ideally be consistent with that.
>
>
> The implementation is essentially just:
>
> self.init(other)
> guard Double(self) == other else {
> return nil
> }
>
> i.e. if the result is not equal to the source when round-tripped back to
> double (which is always exact), the result is nil.
>
> – Steve
>
>
> Pretty much the same trick inside of CFNumber/NSNumber
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 18, 2017, at 9:22 AM, Stephen Canon  wrote:
> 
>> 
>> On Apr 18, 2017, at 12:17 PM, Joe Groff  wrote:
>> 
>> 
>>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
>>> It seems Float.init(exactly: NSNumber) has not been updated to behave 
>>> similarly?
>>> 
>>> I would have to say, I would naively expect "exactly" to behave exactly as 
>>> it says, exactly. I don't think it should be a synonym for 
>>> Float(Double(exactly:)).
>>> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution 
>>>  wrote:
>>> I posted my branch and fixed up the Double case to account for your 
>>> concerns (with a few inspired unit tests to validate)
>>> 
>>> https://github.com/phausler/swift/tree/safe_nsnumber
>>> 
>>> There is a builtin assumption here though: it does presume that the swift’s 
>>> representation of Double and Float are IEEE compliant. However that is a 
>>> fairly reasonable assumption in the tests.
>> 
>> (+Steve Canon) What is the behavior of Float.init(exactly: Double)? 
>> NSNumber's behavior would ideally be consistent with that.
> 
> The implementation is essentially just:
> 
>   self.init(other)
>   guard Double(self) == other else {
>   return nil
>   }
> 
> i.e. if the result is not equal to the source when round-tripped back to 
> double (which is always exact), the result is nil.
> 
> – Steve

Pretty much the same trick inside of CFNumber/NSNumber___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Stephen Canon via swift-evolution]

> On Apr 18, 2017, at 12:17 PM, Joe Groff  wrote:
> 
> 
>> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> It seems Float.init(exactly: NSNumber) has not been updated to behave 
>> similarly?
>> 
>> I would have to say, I would naively expect "exactly" to behave exactly as 
>> it says, exactly. I don't think it should be a synonym for 
>> Float(Double(exactly:)).
>> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution 
>>  wrote:
>> I posted my branch and fixed up the Double case to account for your concerns 
>> (with a few inspired unit tests to validate)
>> 
>> https://github.com/phausler/swift/tree/safe_nsnumber
>> 
>> There is a builtin assumption here though: it does presume that the swift’s 
>> representation of Double and Float are IEEE compliant. However that is a 
>> fairly reasonable assumption in the tests.
> 
> (+Steve Canon) What is the behavior of Float.init(exactly: Double)? 
> NSNumber's behavior would ideally be consistent with that.

The implementation is essentially just:

self.init(other)
guard Double(self) == other else {
return nil
}

i.e. if the result is not equal to the source when round-tripped back to double 
(which is always exact), the result is nil.

– Steve
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Joe Groff via swift-evolution]

> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> It seems Float.init(exactly: NSNumber) has not been updated to behave 
> similarly?
> 
> I would have to say, I would naively expect "exactly" to behave exactly as it 
> says, exactly. I don't think it should be a synonym for 
> Float(Double(exactly:)).
> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution 
>  wrote:
> I posted my branch and fixed up the Double case to account for your concerns 
> (with a few inspired unit tests to validate)
> 
> https://github.com/phausler/swift/tree/safe_nsnumber
> 
> There is a builtin assumption here though: it does presume that the swift’s 
> representation of Double and Float are IEEE compliant. However that is a 
> fairly reasonable assumption in the tests.

(+Steve Canon) What is the behavior of Float.init(exactly: Double)? NSNumber's 
behavior would ideally be consistent with that.

-Joe

>> On Apr 15, 2017, at 13:12, Philippe Hausler  wrote:
>> 
>> 
>> 
>>> On Apr 14, 2017, at 22:51, Martin R  wrote:
>>> 
>>> Thank you for the response, but I have more questions. Will
>>> 
>>> Float(exactly: NSNumber(value: Double.pi))
>> 
>> This will succeed in that the value is representable without loosing mantissa
>> 
>>> 
>>> fail because Float cannot represent the number Double.pi exactly? Or
>>> 
>>> Double(exactly: NSDecimalNumber(string: "1.9”))
>> 
>> Again it would be representable without losing mantissa but… 
>> 
>>> 
>>> because Double cannot represent the decimal fraction 1.9 exactly?
>> 
>> Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope 
>> of this proposal (it is it’s own type and bridges to Decimal)
>> 
>>> 
>>> I find it difficult to evaluate the proposal without a description of the 
>>> intended behavior of the "exact" conversions which covers all possible 
>>> combinations (integers, floating point values, booleans). At present, the 
>>> behavior is described only for stored integer types.
>> 
>> I can post the patch but the real machinery is in NSNumber itself. The 
>> primary test is that if the value can round trip as the expected type and 
>> evaluate to equal to a NSNumber it will.
>> 
>> The conversion roughy is a cast to and from the stored type;
>> 
>> extension Double {
>>  init?(exactly number: NSNumber) {
>>  let value = number.doubleValue
>>  guard NSNumber(value: value) == number else { return nil }
>>  self = value
>>  }
>> }
>> 
>> The effective result of this is a verification of the stored type being 
>> equal to the fetched value. But specifically this only traverses via tagged 
>> pointers (if the are present). It is worth noting that this is not the exact 
>> implementation but an approximation with public apis.
>> 
>> Overall this is by far a better behavior than just permissively allowing all 
>> conversions (which is the current alternative of doing nothing…). As one of 
>> the responsible maintainers for NSNumber I would claim that a generally 
>> permissive cast as it is today is incorrect usage of NSNumber.
>> 
>>> 
>>> Regards, Martin
>>> 
 On 14. Apr 2017, at 23:23, Philippe Hausler  wrote:
 
> 
> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
>  wrote:
> 
> Apologies if I am overlooking something, but it seems to me that the 
> proposal does not clearly define the behavior of the "exact" conversions 
> between integer and floating point values. Does
> 
> Int(exactly: NSNumber(value: 12.34))
 
 The exact value of a float or double constructed NSNumber will only happen 
 for integral values: e.g. 1.0, -32.0 etc
 
> 
> fail because Int cannot represent the number exactly? Or are floating 
> point values truncated silently and the conversion to an integer fails 
> only if it overflows? And the other way around: Does
> 
> Double(exactly: NSNumber(value: Int64(901)))
> 
> fail because Double cannot represent the number exactly?
 
 I believe this will fail because the Int64 value will exceed the mantissa 
 representation of the Double from my current implementation. 
 
> 
> Regards, Martin
> 
>> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
>>  wrote:
>> 
>> Apologies, if you are reading this in HTML the links appear to be 
>> pointing to the incorrect proposal. 
>> 
>> Here is the corrected link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>> 
>>> On Apr 14, 2017, at 11:30 AM, Ben Cohen  wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of “SE-0170: NSNumber bridging and Numeric 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

The unit tests seem to show that is not needed due to the internal 
implementation of NSNumber.

> On Apr 17, 2017, at 17:56, Xiaodi Wu  wrote:
> 
> It seems Float.init(exactly: NSNumber) has not been updated to behave 
> similarly?
> 
> I would have to say, I would naively expect "exactly" to behave exactly as it 
> says, exactly. I don't think it should be a synonym for 
> Float(Double(exactly:)).

There are a few outliers with that: +/-infinity, nan, and values exceeding 
+/-Double(Float.greatestFiniteMagnitude) iiuc will trap in that expression.

If you take a peek at my unit tests; 
https://github.com/phausler/swift/blob/safe_nsnumber/test/stdlib/NSNumberBridging.swift#L800
 


That should verify that float values are properly handled in terms of exactly 
per the casting rules - This is part of the assumption that both float and 
double values in swift are IEEE compliant since NSNumber itself stores 
accordingly. I have tests in place to verify from -1 mantissa bits to +1 
mantissa bits conversions from UInt64 and Int64. 

That all being said: I would be happy to add any additional tests to verify the 
expected behavior.


> On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution 
> > wrote:
> I posted my branch and fixed up the Double case to account for your concerns 
> (with a few inspired unit tests to validate)
> 
> https://github.com/phausler/swift/tree/safe_nsnumber 
> 
> 
> There is a builtin assumption here though: it does presume that the swift’s 
> representation of Double and Float are IEEE compliant. However that is a 
> fairly reasonable assumption in the tests.
> 
>> On Apr 15, 2017, at 13:12, Philippe Hausler > > wrote:
>> 
>> 
>> 
>>> On Apr 14, 2017, at 22:51, Martin R >> > wrote:
>>> 
>>> Thank you for the response, but I have more questions. Will
>>> 
>>> Float(exactly: NSNumber(value: Double.pi))
>> 
>> This will succeed in that the value is representable without loosing mantissa
>> 
>>> 
>>> fail because Float cannot represent the number Double.pi exactly? Or
>>> 
>>> Double(exactly: NSDecimalNumber(string: "1.9”))
>> 
>> Again it would be representable without losing mantissa but… 
>> 
>>> 
>>> because Double cannot represent the decimal fraction 1.9 exactly?
>> 
>> Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope 
>> of this proposal (it is it’s own type and bridges to Decimal)
>> 
>>> 
>>> I find it difficult to evaluate the proposal without a description of the 
>>> intended behavior of the "exact" conversions which covers all possible 
>>> combinations (integers, floating point values, booleans). At present, the 
>>> behavior is described only for stored integer types.
>> 
>> I can post the patch but the real machinery is in NSNumber itself. The 
>> primary test is that if the value can round trip as the expected type and 
>> evaluate to equal to a NSNumber it will.
>> 
>> The conversion roughy is a cast to and from the stored type;
>> 
>> extension Double {
>>  init?(exactly number: NSNumber) {
>>  let value = number.doubleValue
>>  guard NSNumber(value: value) == number else { return nil }
>>  self = value
>>  }
>> }
>> 
>> The effective result of this is a verification of the stored type being 
>> equal to the fetched value. But specifically this only traverses via tagged 
>> pointers (if the are present). It is worth noting that this is not the exact 
>> implementation but an approximation with public apis.
>> 
>> Overall this is by far a better behavior than just permissively allowing all 
>> conversions (which is the current alternative of doing nothing…). As one of 
>> the responsible maintainers for NSNumber I would claim that a generally 
>> permissive cast as it is today is incorrect usage of NSNumber.
>> 
>>> 
>>> Regards, Martin
>>> 
 On 14. Apr 2017, at 23:23, Philippe Hausler > wrote:
 
> 
> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
> > wrote:
> 
> Apologies if I am overlooking something, but it seems to me that the 
> proposal does not clearly define the behavior of the "exact" conversions 
> between integer and floating point values. Does
> 
> Int(exactly: NSNumber(value: 12.34))
 
 The exact value of a float or double constructed NSNumber will only happen 
 for integral values: e.g. 1.0, -32.0 etc
 
> 
> fail because Int cannot represent the number exactly? Or are floating 
> point values truncated silently and the conversion to an 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Xiaodi Wu via swift-evolution]

It seems Float.init(exactly: NSNumber) has not been updated to behave
similarly?

I would have to say, I would naively expect "exactly" to behave exactly as
it says, exactly. I don't think it should be a synonym for
Float(Double(exactly:)).
On Mon, Apr 17, 2017 at 19:24 Philippe Hausler via swift-evolution <
swift-evolution@swift.org> wrote:

> I posted my branch and fixed up the Double case to account for your
> concerns (with a few inspired unit tests to validate)
>
> https://github.com/phausler/swift/tree/safe_nsnumber
>
> There is a builtin assumption here though: it does presume that the
> swift’s representation of Double and Float are IEEE compliant. However that
> is a fairly reasonable assumption in the tests.
>
> On Apr 15, 2017, at 13:12, Philippe Hausler  wrote:
>
>
>
> On Apr 14, 2017, at 22:51, Martin R  wrote:
>
> Thank you for the response, but I have more questions. Will
>
> Float(exactly: NSNumber(value: Double.pi))
>
>
> This will succeed in that the value is representable without loosing
> mantissa
>
>
> fail because Float cannot represent the number Double.pi exactly? Or
>
> Double(exactly: NSDecimalNumber(string: "1.9”))
>
>
> Again it would be representable without losing mantissa but…
>
>
> because Double cannot represent the decimal fraction 1.9 exactly?
>
>
> Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope
> of this proposal (it is it’s own type and bridges to Decimal)
>
>
> I find it difficult to evaluate the proposal without a description of the
> intended behavior of the "exact" conversions which covers all possible
> combinations (integers, floating point values, booleans). At present, the
> behavior is described only for stored integer types.
>
>
> I can post the patch but the real machinery is in NSNumber itself. The
> primary test is that if the value can round trip as the expected type and
> evaluate to equal to a NSNumber it will.
>
> The conversion roughy is a cast to and from the stored type;
>
> extension Double {
> init?(exactly number: NSNumber) {
> let value = number.doubleValue
> guard NSNumber(value: value) == number else { return nil }
> self = value
> }
> }
>
> The effective result of this is a verification of the stored type being
> equal to the fetched value. But specifically this only traverses via tagged
> pointers (if the are present). It is worth noting that this is not the
> exact implementation but an approximation with public apis.
>
> Overall this is by far a better behavior than just permissively allowing
> all conversions (which is the current alternative of doing nothing…). As
> one of the responsible maintainers for NSNumber I would claim that a
> generally permissive cast as it is today is incorrect usage of NSNumber.
>
>
> Regards, Martin
>
> On 14. Apr 2017, at 23:23, Philippe Hausler  wrote:
>
>
> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Apologies if I am overlooking something, but it seems to me that the
> proposal does not clearly define the behavior of the "exact" conversions
> between integer and floating point values. Does
>
> Int(exactly: NSNumber(value: 12.34))
>
>
> The exact value of a float or double constructed NSNumber will only happen
> for integral values: e.g. 1.0, -32.0 etc
>
>
> fail because Int cannot represent the number exactly? Or are floating
> point values truncated silently and the conversion to an integer fails only
> if it overflows? And the other way around: Does
>
> Double(exactly: NSNumber(value: Int64(901)))
>
> fail because Double cannot represent the number exactly?
>
>
> I believe this will fail because the Int64 value will exceed the mantissa
> representation of the Double from my current implementation.
>
>
> Regards, Martin
>
> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Apologies, if you are reading this in HTML the links appear to be pointing
> to the incorrect proposal.
>
> Here is the corrected link:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>
> On Apr 14, 2017, at 11:30 AM, Ben Cohen  wrote:
>
> Hello Swift community,
>
> The review of “SE-0170: NSNumber bridging and Numeric types" begins now
> and runs through the Friday after next, April 14th. The proposal is
> available here:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.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:
> 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

I posted my branch and fixed up the Double case to account for your concerns 
(with a few inspired unit tests to validate)

https://github.com/phausler/swift/tree/safe_nsnumber 


There is a builtin assumption here though: it does presume that the swift’s 
representation of Double and Float are IEEE compliant. However that is a fairly 
reasonable assumption in the tests.

> On Apr 15, 2017, at 13:12, Philippe Hausler  wrote:
> 
> 
> 
>> On Apr 14, 2017, at 22:51, Martin R > > wrote:
>> 
>> Thank you for the response, but I have more questions. Will
>> 
>> Float(exactly: NSNumber(value: Double.pi))
> 
> This will succeed in that the value is representable without loosing mantissa
> 
>> 
>> fail because Float cannot represent the number Double.pi exactly? Or
>> 
>> Double(exactly: NSDecimalNumber(string: "1.9”))
> 
> Again it would be representable without losing mantissa but… 
> 
>> 
>> because Double cannot represent the decimal fraction 1.9 exactly?
> 
> Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope of 
> this proposal (it is it’s own type and bridges to Decimal)
> 
>> 
>> I find it difficult to evaluate the proposal without a description of the 
>> intended behavior of the "exact" conversions which covers all possible 
>> combinations (integers, floating point values, booleans). At present, the 
>> behavior is described only for stored integer types.
> 
> I can post the patch but the real machinery is in NSNumber itself. The 
> primary test is that if the value can round trip as the expected type and 
> evaluate to equal to a NSNumber it will.
> 
> The conversion roughy is a cast to and from the stored type;
> 
> extension Double {
>   init?(exactly number: NSNumber) {
>   let value = number.doubleValue
>   guard NSNumber(value: value) == number else { return nil }
>   self = value
>   }
> }
> 
> The effective result of this is a verification of the stored type being equal 
> to the fetched value. But specifically this only traverses via tagged 
> pointers (if the are present). It is worth noting that this is not the exact 
> implementation but an approximation with public apis.
> 
> Overall this is by far a better behavior than just permissively allowing all 
> conversions (which is the current alternative of doing nothing…). As one of 
> the responsible maintainers for NSNumber I would claim that a generally 
> permissive cast as it is today is incorrect usage of NSNumber.
> 
>> 
>> Regards, Martin
>> 
>>> On 14. Apr 2017, at 23:23, Philippe Hausler >> > wrote:
>>> 
 
 On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
 > wrote:
 
 Apologies if I am overlooking something, but it seems to me that the 
 proposal does not clearly define the behavior of the "exact" conversions 
 between integer and floating point values. Does
 
 Int(exactly: NSNumber(value: 12.34))
>>> 
>>> The exact value of a float or double constructed NSNumber will only happen 
>>> for integral values: e.g. 1.0, -32.0 etc
>>> 
 
 fail because Int cannot represent the number exactly? Or are floating 
 point values truncated silently and the conversion to an integer fails 
 only if it overflows? And the other way around: Does
 
 Double(exactly: NSNumber(value: Int64(901)))
 
 fail because Double cannot represent the number exactly?
>>> 
>>> I believe this will fail because the Int64 value will exceed the mantissa 
>>> representation of the Double from my current implementation. 
>>> 
 
 Regards, Martin
 
> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
> > wrote:
> 
> Apologies, if you are reading this in HTML the links appear to be 
> pointing to the incorrect proposal. 
> 
> Here is the corrected link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>  
> 
> 
>> On Apr 14, 2017, at 11:30 AM, Ben Cohen > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of “SE-0170: NSNumber bridging and Numeric types" begins now 
>> and runs through the Friday after next, April 14th. The proposal is 
>> available here:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>>  
>> 
>> Reviews are an important part of the Swift evolution 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Martin R via swift-evolution]

> On 15. Apr 2017, at 22:12, Philippe Hausler  wrote:
> 
> 
> 
>> On Apr 14, 2017, at 22:51, Martin R > > wrote:
>> 
>> Thank you for the response, but I have more questions. Will
>> 
>> Float(exactly: NSNumber(value: Double.pi))
> 
> This will succeed in that the value is representable without loosing mantissa

Float has shorter mantissa than Double and can not represent Double.pi exactly. 
And it does fail when using the implementation which you provided below:

extension Float {
init?(exactly number: NSNumber) {
let value = number.floatValue
guard NSNumber(value: value) == number else { return nil }
self = value
}
}

print(Float(exactly: NSNumber(value: Double.pi)) as Any)
// nil

On the other hand, a conversion from an Int64 exceeding the mantissa (for which 
you assumed in an earlier reply that it fails) actually succeeds:

extension Double {
init?(exactly number: NSNumber) {
let value = number.doubleValue
guard NSNumber(value: value) == number else { return nil }
self = value
}
}

print(Double(exactly: NSNumber(value: Int64(901))) as Any)
// Optional(9e+18)

>> 
>> fail because Float cannot represent the number Double.pi exactly? Or
>> 
>> Double(exactly: NSDecimalNumber(string: "1.9”))
> 
> Again it would be representable without losing mantissa but… 
> 
>> 
>> because Double cannot represent the decimal fraction 1.9 exactly?
> 
> Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope of 
> this proposal (it is it’s own type and bridges to Decimal)

But NSDecimalNumber is still a subclass of NSNumber, and can represent 1.9 
exactly. Therefore the behavior of 

Double(exactly: someNumberWithIsActuallyAnNSDecimalNumber)

would be interesting.

> 
>> 
>> I find it difficult to evaluate the proposal without a description of the 
>> intended behavior of the "exact" conversions which covers all possible 
>> combinations (integers, floating point values, booleans). At present, the 
>> behavior is described only for stored integer types.
> 
> I can post the patch but the real machinery is in NSNumber itself. The 
> primary test is that if the value can round trip as the expected type and 
> evaluate to equal to a NSNumber it will.
> 
> The conversion roughy is a cast to and from the stored type;
> 
> extension Double {
>   init?(exactly number: NSNumber) {
>   let value = number.doubleValue
>   guard NSNumber(value: value) == number else { return nil }
>   self = value
>   }
> }
> 
> The effective result of this is a verification of the stored type being equal 
> to the fetched value. But specifically this only traverses via tagged 
> pointers (if the are present). It is worth noting that this is not the exact 
> implementation but an approximation with public apis.
> 
> Overall this is by far a better behavior than just permissively allowing all 
> conversions (which is the current alternative of doing nothing…). As one of 
> the responsible maintainers for NSNumber I would claim that a generally 
> permissive cast as it is today is incorrect usage of NSNumber.


I agree that the current behavior is bad and should be improved, and I agree 
with the proprosal with respect to integer values. 

What I still have problems with is how "loss of precision" is (and should be) 
handled for conversions from/to/between floating point values. The above 
examples show an inconsistent behaviour: 

print(Float(exactly: NSNumber(value: Double.pi)) as Any)
// nil

print(Double(exactly: NSNumber(value: Int64(901))) as Any)
// Optional(9e+18)

but perhaps the real implementation will behave differently. 

When obtaining a NSNumber from some API  one cannot know if the number is 
internally represented as Double or Float or is actually a NSDecimalNumber. 
Therefore is seems impractical to me if Float(exactly: someNumber) failed if 
precision were lost during the conversion.

Regards, Martin

> 
>> 
>> Regards, Martin
>> 
>>> On 14. Apr 2017, at 23:23, Philippe Hausler >> > wrote:
>>> 
 
 On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
 > wrote:
 
 Apologies if I am overlooking something, but it seems to me that the 
 proposal does not clearly define the behavior of the "exact" conversions 
 between integer and floating point values. Does
 
 Int(exactly: NSNumber(value: 12.34))
>>> 
>>> The exact value of a float or double constructed NSNumber will only happen 
>>> for integral values: e.g. 1.0, -32.0 etc
>>> 
 
 fail because Int cannot represent the number exactly? Or are floating 
 point values truncated silently and 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 14, 2017, at 22:51, Martin R  wrote:
> 
> Thank you for the response, but I have more questions. Will
> 
> Float(exactly: NSNumber(value: Double.pi))

This will succeed in that the value is representable without loosing mantissa

> 
> fail because Float cannot represent the number Double.pi exactly? Or
> 
> Double(exactly: NSDecimalNumber(string: "1.9”))

Again it would be representable without losing mantissa but… 

> 
> because Double cannot represent the decimal fraction 1.9 exactly?

Neither can NSDecimalNumber btw ;X and NSDecimalNumber is not in the scope of 
this proposal (it is it’s own type and bridges to Decimal)

> 
> I find it difficult to evaluate the proposal without a description of the 
> intended behavior of the "exact" conversions which covers all possible 
> combinations (integers, floating point values, booleans). At present, the 
> behavior is described only for stored integer types.

I can post the patch but the real machinery is in NSNumber itself. The primary 
test is that if the value can round trip as the expected type and evaluate to 
equal to a NSNumber it will.

The conversion roughy is a cast to and from the stored type;

extension Double {
init?(exactly number: NSNumber) {
let value = number.doubleValue
guard NSNumber(value: value) == number else { return nil }
self = value
}
}

The effective result of this is a verification of the stored type being equal 
to the fetched value. But specifically this only traverses via tagged pointers 
(if the are present). It is worth noting that this is not the exact 
implementation but an approximation with public apis.

Overall this is by far a better behavior than just permissively allowing all 
conversions (which is the current alternative of doing nothing…). As one of the 
responsible maintainers for NSNumber I would claim that a generally permissive 
cast as it is today is incorrect usage of NSNumber.

> 
> Regards, Martin
> 
>> On 14. Apr 2017, at 23:23, Philippe Hausler > > wrote:
>> 
>>> 
>>> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
>>> > wrote:
>>> 
>>> Apologies if I am overlooking something, but it seems to me that the 
>>> proposal does not clearly define the behavior of the "exact" conversions 
>>> between integer and floating point values. Does
>>> 
>>> Int(exactly: NSNumber(value: 12.34))
>> 
>> The exact value of a float or double constructed NSNumber will only happen 
>> for integral values: e.g. 1.0, -32.0 etc
>> 
>>> 
>>> fail because Int cannot represent the number exactly? Or are floating point 
>>> values truncated silently and the conversion to an integer fails only if it 
>>> overflows? And the other way around: Does
>>> 
>>> Double(exactly: NSNumber(value: Int64(901)))
>>> 
>>> fail because Double cannot represent the number exactly?
>> 
>> I believe this will fail because the Int64 value will exceed the mantissa 
>> representation of the Double from my current implementation. 
>> 
>>> 
>>> Regards, Martin
>>> 
 On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
 > wrote:
 
 Apologies, if you are reading this in HTML the links appear to be pointing 
 to the incorrect proposal. 
 
 Here is the corrected link:
 
 https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
  
 
 
> On Apr 14, 2017, at 11:30 AM, Ben Cohen  > wrote:
> 
> Hello Swift community,
> 
> The review of “SE-0170: NSNumber bridging and Numeric types" begins now 
> and runs through the Friday after next, April 14th. The proposal is 
> available here:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.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/0170-nsnumber_bridge.md
>  
> 
> 
>   Reply text
> 
>   Other replies

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Martin R via swift-evolution]

Thank you for the response, but I have more questions. Will

Float(exactly: NSNumber(value: Double.pi))

fail because Float cannot represent the number Double.pi exactly? Or

Double(exactly: NSDecimalNumber(string: "1.9"))

because Double cannot represent the decimal fraction 1.9 exactly?

I find it difficult to evaluate the proposal without a description of the 
intended behavior of the "exact" conversions which covers all possible 
combinations (integers, floating point values, booleans). At present, the 
behavior is described only for stored integer types.

Regards, Martin

> On 14. Apr 2017, at 23:23, Philippe Hausler  wrote:
> 
>> 
>> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
>> > wrote:
>> 
>> Apologies if I am overlooking something, but it seems to me that the 
>> proposal does not clearly define the behavior of the "exact" conversions 
>> between integer and floating point values. Does
>> 
>> Int(exactly: NSNumber(value: 12.34))
> 
> The exact value of a float or double constructed NSNumber will only happen 
> for integral values: e.g. 1.0, -32.0 etc
> 
>> 
>> fail because Int cannot represent the number exactly? Or are floating point 
>> values truncated silently and the conversion to an integer fails only if it 
>> overflows? And the other way around: Does
>> 
>> Double(exactly: NSNumber(value: Int64(901)))
>> 
>> fail because Double cannot represent the number exactly?
> 
> I believe this will fail because the Int64 value will exceed the mantissa 
> representation of the Double from my current implementation. 
> 
>> 
>> Regards, Martin
>> 
>>> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
>>> > wrote:
>>> 
>>> Apologies, if you are reading this in HTML the links appear to be pointing 
>>> to the incorrect proposal. 
>>> 
>>> Here is the corrected link:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>>>  
>>> 
>>> 
 On Apr 14, 2017, at 11:30 AM, Ben Cohen > wrote:
 
 Hello Swift community,
 
 The review of “SE-0170: NSNumber bridging and Numeric types" begins now 
 and runs through the Friday after next, April 14th. The proposal is 
 available here:

 https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.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/0170-nsnumber_bridge.md
  
 
 
Reply text
 
Other replies
 
 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,
 
 Ben Cohen
 Review Manager
 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> 

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Matthew Johnson via swift-evolution]

> 
>   • What is your evaluation of the proposal?

+1.  I have run into problems with the current behavior a few times.  This 
proposal brings the behavior in-line with what I believe is best.

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

Yes.

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

Yes.  It continues the trend of refining the behavior of Objetive-C and Cocoa 
bridging.

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

I have not worked in a language with the kind of first-class bridging Swift has.

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

I was the author of SE-0080 and wanted to include similar provisions in that 
proposal early on so I think it’s fair to say an in-depth study.  I’m happy to 
see the Foundation side of this topic receiving attention.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Philippe Hausler via swift-evolution]

> On Apr 14, 2017, at 2:11 PM, Martin R via swift-evolution 
>  wrote:
> 
> Apologies if I am overlooking something, but it seems to me that the proposal 
> does not clearly define the behavior of the "exact" conversions between 
> integer and floating point values. Does
> 
> Int(exactly: NSNumber(value: 12.34))

The exact value of a float or double constructed NSNumber will only happen for 
integral values: e.g. 1.0, -32.0 etc

> 
> fail because Int cannot represent the number exactly? Or are floating point 
> values truncated silently and the conversion to an integer fails only if it 
> overflows? And the other way around: Does
> 
> Double(exactly: NSNumber(value: Int64(901)))
> 
> fail because Double cannot represent the number exactly?

I believe this will fail because the Int64 value will exceed the mantissa 
representation of the Double from my current implementation. 

> 
> Regards, Martin
> 
>> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
>> > wrote:
>> 
>> Apologies, if you are reading this in HTML the links appear to be pointing 
>> to the incorrect proposal. 
>> 
>> Here is the corrected link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>>  
>> 
>> 
>>> On Apr 14, 2017, at 11:30 AM, Ben Cohen >> > wrote:
>>> 
>>> Hello Swift community,
>>> 
>>> The review of “SE-0170: NSNumber bridging and Numeric types" begins now and 
>>> runs through the Friday after next, April 14th. The proposal is available 
>>> here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.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/0170-nsnumber_bridge.md
>>>  
>>> 
>>> 
>>> Reply text
>>> 
>>> Other replies
>>> 
>>> 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,
>>> 
>>> Ben Cohen
>>> Review Manager
>>> 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> 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

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

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Martin R via swift-evolution]

Apologies if I am overlooking something, but it seems to me that the proposal 
does not clearly define the behavior of the "exact" conversions between integer 
and floating point values. Does

Int(exactly: NSNumber(value: 12.34))

fail because Int cannot represent the number exactly? Or are floating point 
values truncated silently and the conversion to an integer fails only if it 
overflows? And the other way around: Does

Double(exactly: NSNumber(value: Int64(901)))

fail because Double cannot represent the number exactly?

Regards, Martin

> On 14. Apr 2017, at 20:45, Ben Cohen via swift-evolution 
>  wrote:
> 
> Apologies, if you are reading this in HTML the links appear to be pointing to 
> the incorrect proposal. 
> 
> Here is the corrected link:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md
>  
> 
> 
>> On Apr 14, 2017, at 11:30 AM, Ben Cohen > > wrote:
>> 
>> Hello Swift community,
>> 
>> The review of “SE-0170: NSNumber bridging and Numeric types" begins now and 
>> runs through the Friday after next, April 14th. The proposal is available 
>> here:
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.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/0170-nsnumber_bridge.md
>>  
>> 
>> 
>>  Reply text
>> 
>>  Other replies
>> 
>> 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,
>> 
>> Ben Cohen
>> Review Manager
>> 
>> 
> 
> ___
> swift-evolution mailing list
> 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

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

[Ben Cohen via swift-evolution]

Apologies, if you are reading this in HTML the links appear to be pointing to 
the incorrect proposal. 

Here is the corrected link:

https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md

> On Apr 14, 2017, at 11:30 AM, Ben Cohen  wrote:
> 
> Hello Swift community,
> 
> The review of “SE-0170: NSNumber bridging and Numeric types" begins now and 
> runs through the Friday after next, April 14th. The proposal is available 
> here:
>   
> https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.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/0170-nsnumber_bridge.md
> 
>   Reply text
> 
>   Other replies
> 
> 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,
> 
> Ben Cohen
> Review Manager
> 
> 

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