3 ms·

Static and concise NPE protection via optional syntax, and the guard construct, both make defensive programming much easier in Swift. Tons of other little thing

Static and concise NPE protection via optional syntax, and the guard construct, both make defensive programming much easier in Swift. Tons of other little things. Memory management is easier than it is in Rust. It has generics which makes it more flexible than Go [was until its generics were recently introduced]. Kotlin native wasn’t announced until three years after Swift. I don’t think it’s as simple or one-sided as you’re making it out to be.

nmfisher 4y ago
I don't consider this: guard let foo = bar else { ... } to be any better than this: if bar().is_none() { ... } For the record, I find the guard keyword totally unnecessary and I still have NFI what's wrong with this in Swift: if bar == nil { ... } I also totally disagree about memory management being "easier" (at least with C-interop), because I think Swift's handling of UnsafePointer/UnsafeRawPointer/UnsafeBufferPointer/mutable variants/withMemoryRebound/etc isn't particularly easy to follow at all. To be clear though: I don't think Swift is a bad language. It's perfectly adequate. But it's the fact that Apple decided to force Yet Another Programming Language down our throats that, in my opinion, offers no real advantage over many of the other choices available at the time. "We're Apple and you will only use a language that we control" was, IMO, the driving force behind Swift, not the inherent superiority of the language itself.
- fingerlocks 4y ago
  The guard keyword behaves like a non-crashing assertion that promotes code readability with a compile-time required early exit. “Don’t bother executing past this point if these conditions are not met” is fundamentally different from “if these conditions are met create a new local scope and then continue executing”. > Swift's handling of UnsafePointer/UnsafeRawPointer/UnsafeBufferPointer/mutable variants/withMemoryRebound/etc isn't particularly easy to follow at all. And that’s why we have inout instead? Unsafe* is useful if you need to bit pack frozen structs into a ring buffer and increment the r/w offsets by the stride, maybe? I think inout can handle that as well.
- sixstringtheory 4y ago
  In addition to what replies have already pointed out to you, guard places the assigned new variable in the same scope below. This encourages early exits and avoids pyramids of doom.

nmfisher 4y ago

I don't consider this: guard let foo = bar else { ... } to be any better than this: if bar().is_none() { ... } For the record, I find the guard keyword totally unnecessary and I still have NFI what's wrong with this in Swift: if bar == nil { ... } I also totally disagree about memory management being "easier" (at least with C-interop), because I think Swift's handling of UnsafePointer/UnsafeRawPointer/UnsafeBufferPointer/mutable variants/withMemoryRebound/etc isn't particularly easy to follow at all. To be clear though: I don't think Swift is a bad language. It's perfectly adequate. But it's the fact that Apple decided to force Yet Another Programming Language down our throats that, in my opinion, offers no real advantage over many of the other choices available at the time. "We're Apple and you will only use a language that we control" was, IMO, the driving force behind Swift, not the inherent superiority of the language itself.

fingerlocks 4y ago
The guard keyword behaves like a non-crashing assertion that promotes code readability with a compile-time required early exit. “Don’t bother executing past this point if these conditions are not met” is fundamentally different from “if these conditions are met create a new local scope and then continue executing”. > Swift's handling of UnsafePointer/UnsafeRawPointer/UnsafeBufferPointer/mutable variants/withMemoryRebound/etc isn't particularly easy to follow at all. And that’s why we have inout instead? Unsafe* is useful if you need to bit pack frozen structs into a ring buffer and increment the r/w offsets by the stride, maybe? I think inout can handle that as well.
sixstringtheory 4y ago
In addition to what replies have already pointed out to you, guard places the assigned new variable in the same scope below. This encourages early exits and avoids pyramids of doom.