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 Monroe <[email protected]> wrote: > 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 May 15, 2017, at 1:09 PM, T.J. Usiyan via swift-evolution < > [email protected]> wrote: > > 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, 2017 at 5:52 AM, Kenny Leung via swift-evolution < > [email protected]> wrote: > >> > On May 12, 2017, at 9:56 AM, John McCall via swift-evolution < >> [email protected]> 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 this reasoning. I’ve had cause to distinguish 0 from >> null in both Objective-C and Java, and I would do exactly the same thing. >> >> -Kenny >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
