3 ms·

How is Swift safer than Obj-C? I'm not sarcastic or anything by the way, I just don't understand yet the foundation behind that statement.

orkoden 12y ago
It does not have features that often lead to bugs. E.g. the switch statement does not allow fall through and enforces a default case.
- m_mueller 12y ago
  The lack of fall through makes me a bit sad since I think that it's a very powerful programming construct and it usually only hurts people new to the concept - but of course one can live without it.
  - mantrax5 12y ago
    Three things. First of all, while you can't do this: case val: case val: case val: ... You can do this in Swift, which does the same thing: case val, val, val: ... Second, you can fall through in Swift, but you need to ask for it: case val: ... fallthrough case val: ... So don't be sad. And third... Seriously now, it's a "very powerful programming concept"? I bet 9 times out of 10 you use this very powerful programming concept in other languages, you did it by accident, not because you needed its pawa.
    - m_mueller 12y ago
      Thanks for the clarification on how to use it in Swift - like this it's indeed the perfect solution by enforcing it to be explicit. Having multiple cases rolled into one is also a very nice option. The snark wasn't really called for though. No, I don't 'use' it by accident, that would in most cases just become a bug. I use it when it makes code more concise rather than having nested ifs. Consider for example ACL rules where you set different privileges by default according to an access level.
swiftlies 12y ago
Are we talking about type safety or general security? Either way, Swift does better than ObjC in both regards. ObjC was exceptionally type-unsafe. Any object type could be implicitly converted to and from the `id` type: NSString* foo = @"hello world!"; id bar = foo; // no warning NSDictionary* baz = foo; // no warning The Foundation collections all used `id` for the values and keys when they had keys. `NSDictionary` will accept any object as a key, even though it will only work if the key is copiable and hashable, and it does mean that you could have keys of fundamentally different types in the same collection. Values can be heterogeneous too. As far as type safety goes, Swift is on par with modern languages. ObjC also inherited several security issues of the C language, like unchecked arrays and unchecked arithmetic. Swift performs bounds checking by default (you can manipulate raw arrays with `UnsafePointer<T>`) and has checked arithmetic by default (you can allow overflows by prefixing the operator with `&`, so `&*`, `&+`, etc). It also never requires you to allocate and deallocate buffers yourself. So Swift is more secure because it has no buffer overflows, no integer overflows (though they're more an issue when you have buffer overflows) and no unsafe memory management. These are by far the three most commonly exploited vulnerabilities in software.
- m_mueller 12y ago
  Thanks for your elaborate answer, I very much appreciate it. After these discussions, Swift sounds like adopting the best of the worlds of fast and dangerous (C, C++, Fortran), slow and easy (Python, Ruby) and slow and safe (Haskell) languages (I'm listing the extreme examples here from my perspective rather than the actual influences to Swift). I especially like the 'safe by default - unsafe optional' stance, since this gives you the ability to create a working program quickly, but still optimise it later through introducing unsafe behaviour. This can allow Swift to be used for HPC purposes further down the road (provided [1] substantial parts will get Open Sourced, [2] it gets implemented on Linux and [3] it gets support for parallel computing both on node, core and accelerator level). Without having worked with it yet, here's what I'd love to get in order to use it for HPC: -UnsafeButWarn compiler options -> replaces safe versions of arithmetic / arrays with unsafe ones, but issue runtime warnings whenever unsafe behaviour has occurred. Meant for debugging the runtime into never going unsafe, such that checks can be disabled. -Unsafe compiler option -> replaces safe operations with unsafe ones. Meant for the production version that has been extensively tested but needs to run as fast as possible.
KMag 12y ago
For one, Swift avoids what Tony Hoare calls his Billion Dollar Mistake (conflating optionality and reference types). Because Tony Hoare introduced null references to Algol W, most Algol-derived and Algol-inspired statically typed languages since have made all pointers/references nullable. Some, like Java, have bolted on Lint-like null checkers an afterthought (see @Nullable, @NotNull) outside of the official compiler. It's really nice to have the compiler not allow callers to pass null to functions where passing null wouldn't make sense, isn't useful, or the programmer was just too lazy to implement null checks. More than half of the functions I write have inputs where null wouldn't have an obvious meaning. Objective-C's treatment of nil receivers is particularly handy for programming in the small and particularly bad for programming in the large. Sending a message to nil (similar to calling a method on null in many other languages) does nothing other than returning 0 cast to the type of variable you're storing the return value in. Chugging along accidentally accumulating nulls in many cases is worse than segfaulting and giving a nice stack trace. Certainly in the realm of automated trading software, segfaulting when hitting a programming error is preferable to most other failure modes. Of course, failing to compile is often (though not always) the best failure mode.

orkoden 12y ago

It does not have features that often lead to bugs. E.g. the switch statement does not allow fall through and enforces a default case.

m_mueller 12y ago
The lack of fall through makes me a bit sad since I think that it's a very powerful programming construct and it usually only hurts people new to the concept - but of course one can live without it.
- mantrax5 12y ago
  Three things. First of all, while you can't do this: case val: case val: case val: ... You can do this in Swift, which does the same thing: case val, val, val: ... Second, you can fall through in Swift, but you need to ask for it: case val: ... fallthrough case val: ... So don't be sad. And third... Seriously now, it's a "very powerful programming concept"? I bet 9 times out of 10 you use this very powerful programming concept in other languages, you did it by accident, not because you needed its pawa.
  - m_mueller 12y ago
    Thanks for the clarification on how to use it in Swift - like this it's indeed the perfect solution by enforcing it to be explicit. Having multiple cases rolled into one is also a very nice option. The snark wasn't really called for though. No, I don't 'use' it by accident, that would in most cases just become a bug. I use it when it makes code more concise rather than having nested ifs. Consider for example ACL rules where you set different privileges by default according to an access level.

swiftlies 12y ago

Are we talking about type safety or general security? Either way, Swift does better than ObjC in both regards. ObjC was exceptionally type-unsafe. Any object type could be implicitly converted to and from the `id` type: NSString* foo = @"hello world!"; id bar = foo; // no warning NSDictionary* baz = foo; // no warning The Foundation collections all used `id` for the values and keys when they had keys. `NSDictionary` will accept any object as a key, even though it will only work if the key is copiable and hashable, and it does mean that you could have keys of fundamentally different types in the same collection. Values can be heterogeneous too. As far as type safety goes, Swift is on par with modern languages. ObjC also inherited several security issues of the C language, like unchecked arrays and unchecked arithmetic. Swift performs bounds checking by default (you can manipulate raw arrays with `UnsafePointer<T>`) and has checked arithmetic by default (you can allow overflows by prefixing the operator with `&`, so `&*`, `&+`, etc). It also never requires you to allocate and deallocate buffers yourself. So Swift is more secure because it has no buffer overflows, no integer overflows (though they're more an issue when you have buffer overflows) and no unsafe memory management. These are by far the three most commonly exploited vulnerabilities in software.

m_mueller 12y ago
Thanks for your elaborate answer, I very much appreciate it. After these discussions, Swift sounds like adopting the best of the worlds of fast and dangerous (C, C++, Fortran), slow and easy (Python, Ruby) and slow and safe (Haskell) languages (I'm listing the extreme examples here from my perspective rather than the actual influences to Swift). I especially like the 'safe by default - unsafe optional' stance, since this gives you the ability to create a working program quickly, but still optimise it later through introducing unsafe behaviour. This can allow Swift to be used for HPC purposes further down the road (provided [1] substantial parts will get Open Sourced, [2] it gets implemented on Linux and [3] it gets support for parallel computing both on node, core and accelerator level). Without having worked with it yet, here's what I'd love to get in order to use it for HPC: -UnsafeButWarn compiler options -> replaces safe versions of arithmetic / arrays with unsafe ones, but issue runtime warnings whenever unsafe behaviour has occurred. Meant for debugging the runtime into never going unsafe, such that checks can be disabled. -Unsafe compiler option -> replaces safe operations with unsafe ones. Meant for the production version that has been extensively tested but needs to run as fast as possible.

KMag 12y ago

For one, Swift avoids what Tony Hoare calls his Billion Dollar Mistake (conflating optionality and reference types). Because Tony Hoare introduced null references to Algol W, most Algol-derived and Algol-inspired statically typed languages since have made all pointers/references nullable. Some, like Java, have bolted on Lint-like null checkers an afterthought (see @Nullable, @NotNull) outside of the official compiler. It's really nice to have the compiler not allow callers to pass null to functions where passing null wouldn't make sense, isn't useful, or the programmer was just too lazy to implement null checks. More than half of the functions I write have inputs where null wouldn't have an obvious meaning. Objective-C's treatment of nil receivers is particularly handy for programming in the small and particularly bad for programming in the large. Sending a message to nil (similar to calling a method on null in many other languages) does nothing other than returning 0 cast to the type of variable you're storing the return value in. Chugging along accidentally accumulating nulls in many cases is worse than segfaulting and giving a nice stack trace. Certainly in the realm of automated trading software, segfaulting when hitting a programming error is preferable to most other failure modes. Of course, failing to compile is often (though not always) the best failure mode.