Sure, you can see what Swift solves, based on the experience of not writing in Swift. That doesn't tell you what new kinds of bugs Swift enables, though. It's going to take years of using it to find out. You can somewhat speed that up by doing a full analysis of the bugs you get using the new language.
>Sure, you can see what Swift solves, based on the experience of not writing in Swift.
That's actually not true. You can see the trivial stuff it solves from the promo materials - you don't know the full extent of what's realistically possible to encode in the type system.
I had this thought yesterday writing C++ code - I was doing some re factoring and I copy pasted the same identifier twice instead of writing data to two separate buffers. The case where this mattered was not covered by unit testing because it's an edge case in a tightly coupled part - it's a major chore to test that kind of code for little gain.
My first instinct was "just put unit test there and forget about it" but on the other hand while buffer API is the same two buffers are semantically different so I could have made them two distinct types (eg. with template argument tag) and required untyped input buffer to be wrapped in a type explicitly stating data use case - this would have made the bug obvious and compiler would catch any discrepancy.
My point is there are plenty of non-obvious ways to prevent bugs trough a strong type system.
Well, you can start with all of the things that Objective C has that Swift does not that are likely to cause bugs.
For example, static analysis returns nothing where it did something before. Not calling super.viewWillAppear() in a subclass does not raise the appropriate warning in Swift.
