>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 t

>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.