Hmm... May be I misunderstood something

Hmm... May be I misunderstood something

Actually, given an expressive type system, the formal interface would change for that change in meaning. For example, using a type system comparable to that of Haskell (but C-ish syntax), I could define a function Storeys buildingHeightInStoreys( Metres<Int> length );. When I change that function to work in inches, it becomes Storeys buildingHeightInStoreys( Inches<Int> length );.

Throw in type inference, and you get some of the benefits of dynamic languages like Python. Again, using C-ish syntax, I could declare a function USDollars estimatedRent( auto height );, and write suitable behaviour for each variation on height (perhaps by unifying on height in storeys, and estimating from there).

Having said all that, it's a tradeoff in terms of work - the question is not whether static types are enough to stop all bugs on their own, but whether the reduction in tests that they permit is outweighed by the cost of static types. I believe that in C, this isn't true. In Haskell, however, people claim that it is true; this is one that remains to be tested more formally.