Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

> On May 22, 2017, at 6:07 AM, Ben Rimmington wrote: > > >> On 20 May 2017, at 19:58, Philippe Hausler wrote: >> >>> On May 20, 2017, at 12:25 AM, David Waite wrote: >>> >>> I believe behavior depends on whether the NSNumber is the objc type or >>> swift subtype,

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

> On 20 May 2017, at 19:58, Philippe Hausler wrote: > >> On May 20, 2017, at 12:25 AM, David Waite wrote: >> >> I believe behavior depends on whether the NSNumber is the objc type or swift >> subtype, and whether you call the NSNumber.intValue or use >> Int.init?(exactly: NSNumber). > > That

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

> On May 20, 2017, at 12:47 PM, Philippe Hausler wrote: > > With the introduction of SE-0170 the behavior is a bit more predicable: The > rule is that if the value would not loose mantissa representation or > significant bits of the representation it will bridge to the

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

> On May 20, 2017, at 12:25 AM, David Waite via swift-evolution > wrote: > > I believe behavior depends on whether the NSNumber is the objc type or swift > subtype, and whether you call the NSNumber.intValue or use Int.init?(exactly: > NSNumber). > That part of

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

With the introduction of SE-0170 the behavior is a bit more predicable: The rule is that if the value would not loose mantissa representation or significant bits of the representation it will bridge to the target type in all scenarios, no matter if it is created in objc or in swift. > On May

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

I believe behavior depends on whether the NSNumber is the objc type or swift subtype, and whether you call the NSNumber.intValue or use Int.init?(exactly: NSNumber). My point is that there is no intuitive or safe generalized behavior for treating arbitrary NSNumbers as an Int? . If an

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

What happens now if you call integerValue if a NSNumber has these values? > On May 19, 2017, at 9:00 PM, David Waite wrote: > > When I call such a mapped Swift API that expects an Int? parameter from Objc > with a NSNumber initialized with 3.5, what should

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

When I call such a mapped Swift API that expects an Int? parameter from Objc with a NSNumber initialized with 3.5, what should happen? [NSNumber uint64value: UINT64_MAX] ? What about the float 1e100? What about boolean 'true’? NaN? -DW > On May 19, 2017, at 8:54 PM, Jonathan Hull via

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

I have to side with Kenny on this one. I would find losing nil vs 0 more surprising than NSInteger vs NSNumber. In fact, I was surprised that this doesn’t already cross to a NSNumber. That would be the behavior I expect. Thanks, Jon > On May 16, 2017, at 11:51 AM, Kenny Leung via

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

Once again, the counter-argument is the the same. Before there was Swift, this is exactly what we would do, and it was never a surprise. I would say the semantics of wrapped API should be taken from the viewpoint of the target language (ObjC), and not from the viewpoint of Swift. -Kenny > On

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

> On May 15, 2017, at 8:24 AM, T.J. Usiyan via swift-evolution > wrote: > > The argument is not about whether or not it should come through as an object. > The argument is about the fact that *sometimes* it would come through as an > object and other times it would

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

But my argument *is* that optionality is an obvious way to make that decision. If I was writing in pure Objective-C (outside the context of Swift), sometimes I would have methods that take or return int, and sometimes I would have methods that take or return NSNumber. There is never really a

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

The argument is not about whether or not it should come through as an object. The argument is about the fact that *sometimes* it would come through as an object and other times it would not. Optionality isn't an obvious way to make that decision. TJ On Mon, May 15, 2017 at 3:03 PM, Charlie

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

This is not much of an argument given that NSString is an object in ObjC (heap-allocated), String in Swift is an struct and also given that most NSNumber's nowadays are not really allocated, but just tagged pointers. Given that NSNumber is immutable, you get the value semantics anyway... > On

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

My understanding of the reasoning is that `NSNumber` is an object in Objective-C and not a struct. There is already one level of decision when translating to objc in that regard. Switching between reference semantics/class and value semantics because of optionality is surprising. On Mon, May 15,

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

> On May 12, 2017, at 9:56 AM, John McCall via swift-evolution > wrote: > Exporting Int? as an optional NSNumber does not feel obvious and idiomatic > when we would export Int as NSInteger. It feels like reaching for an > arbitrary solution. I don’t understand

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

> On May 12, 2017, at 1:18 PM, Víctor Pimentel Rodríguez > wrote: > On Fri, May 12, 2017 at 6:56 PM, John McCall via swift-evolution > > wrote: > I assume you're talking about the type restrictions on exporting

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

On Fri, May 12, 2017 at 6:56 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > I assume you're talking about the type restrictions on exporting Swift > functions as @objc. We have the technical ability to bridge any Swift > value to Objective-C as an opaque object, but

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

> On May 12, 2017, at 10:10 AM, Yarik Arsenkin via swift-evolution > wrote: > Hi, > > does anyone know if there is a reason why bridging of the Swift’s `Int?` type > doesn’t work for Objective-C? I mean, it could be exposed as an `NSNumber` > with nullable

[swift-evolution] Swift's Optional Int as NSNumber in Objective-C

Hi, does anyone know if there is a reason why bridging of the Swift’s `Int?` type doesn’t work for Objective-C? I mean, it could be exposed as an `NSNumber` with nullable attribute, no? Cheers, Yarik ___ swift-evolution mailing list