Using Swift or NS Data Types?

[Alex Hall]

Hi list,
Possibly a dumb question, but should those using Swift still make heavy use of NS types (NSNumber, NSString, and so on)? Obviously there are times when it is necessary, but from what I've read, using these types in ObjC is often a convention - a good one, but a convention. For instance, NSNumbers will always make your code 64-bit safe, whereas ints do not.

In sample code for Swift, I always see Int, String, Double, and other non-NS types being used. Is this simply to avoid the added complexity of using NS types in Swift when all the author wants to do is show how a function is written, or can Swift coders safely rely on Swift's own data types? Again, I know there are times when NS is required, but it seems like you can often ignore it and use native Swift types. Is doing so safe and/or recommended? Is it just too early to even tell yet?

--

Have a great day,

Alex Hall

meh...@icloud.com

[Marco S Hyman]

> Possibly a dumb question, but should those using Swift still make heavy use of NS types (NSNumber, NSString, and so on)?

My take (pure opinion, no fact) is to use Swift native types where
possible and NS types where necessary. That hasn't hurt me, yet. If I need to worry about large numbers I'll use Int64 instead of Int.

Marc

[Jens Alfke]

On Aug 3, 2014, at 2:18 PM, Alex Hall <meh...@icloud.com> wrote:

from what I've read, using these types in ObjC is often a convention - a good one, but a convention.

It’s not a convention, it’s necessary for “boxing” built-in numeric types so they can be treated as objects and used with OO APIs like containers.

For instance, NSNumbers will always make your code 64-bit safe, whereas ints do not.

NSNumber has nothing to do with 64-bit safety. 

Are you getting NSNumber mixed up with NSInteger? (And there’s nothing magic about NSInteger either. It’s just a typedef for either ‘int’ or ‘long’.)

—Jens

[Fritz Anderson]

On Aug 3, 2014, at 4:18 PM, Alex Hall <meh...@icloud.com> wrote:

> Possibly a dumb question, but should those using Swift still make heavy use of NS types (NSNumber, NSString, and so on)? Obviously there are times when it is necessary, but from what I've read, using these types in ObjC is often a convention - a good one, but a convention. For instance, NSNumbers will always make your code 64-bit safe, whereas ints do not.
>
> In sample code for Swift, I always see Int, String, Double, and other non-NS types being used. Is this simply to avoid the added complexity of using NS types in Swift when all the author wants to do is show how a function is written, or can Swift coders safely rely on Swift's own data types? Again, I know there are times when NS is required, but it seems like you can often ignore it and use native Swift types. Is doing so safe and/or recommended? Is it just too early to even tell yet?

I have a hard time following your terminology (I often do, it’s not you), so my answer will include some things that are obvious, either from reading the documentation (which I highly recommend) or a priori. I am sure I am missing your real point.

What I’m about to say is tempered by the fact that this is a fairly-early beta of a completely-new language deployed in a beta environment that experience has shown won’t settle down until 6.0.2 or 6.1.1 (sorry DevTools). What seem to be exceptions today may simply be bugs or design omissions.

• Swift is designed with “safety” as a capital goal. If you mean “do they work,” they are intended to be as reliable as anything ever is. Have a look at the provisions for numeric overflow; Swift prevents or fails upon overflow unless you use special operators to take control of the exceptions.

• Swift is meant to work with Objective-C frameworks with essentially no sacrifice in safety. Crossing between Swift and Foundation data without special gestures is a compulsory feature of the language. It is not an afterthought. The use of Swift primitives is to be normal coding practice, not a simplification for illustration. What look like (and may be implemented as) primitives in Swift are supposed to cross over into their Foundation equivalents (_and_ C scalars) as you would intuit. (It’s a beta, cut it some slack.)

• As you suggest, the Swift library is thinner than you’d expect from a modern language. That’s because what you’d expect from a standard library is already mature and safe in Foundation. Safer, because things like strings and scalars don’t get into Foundation until Swift’s own safety régime has accepted them. It’s not a matter of “there are times that…,” Cocoa _is_ the library.** If the bridge didn’t provide full service as you would expect,*** Swift would be unfit for release.

** (That’s the line today, no conditions, no exceptions except for necessities the designers have worked hard to minimize. The necessities are not “unsafe” or “undefined,” the compiler actively forbids them, or demands blatant gestures to show you know what you’re doing.)

*** (Plus or minus type-casting hell.)

Now tell me what I’ve missed.

— F