, Bass wrote

Again, all you are arguing for is a extremely limited form of code contracts. Adding a bunch of complexity to a language to do something other languages do, poorly is not really a good idea.

On the contrary. I think making types more powerful makes code better. That's why when I write code in C/C++ I use __in, __inout, const, __notnull and all sorts of other annotations to make my code better. I run static analysis tools to find unit-cases where a null-dereference or buffer overflow might occur that it finds algebraically rather than requiring me to think of it in advance in the unit tests.

That's why I really love Spec#. It's a way of building your unit tests inline with your code - and not only do your unit tests get auto-tested on each build, but the tests are algebraic (and therefore complete) rather than ad-hoc, and your compiler gets the opportunity to omit checks that it doesn't need because they are contractually verified.

All your apparent vulnerabilities effect static languages as well

They only affect it where data becomes typeless. SQL injection is because you're mixing SQL code and attacker controlled data. A static typed approach would be to say that SQL code simply doesn't compose with the attacker controlled string, and hence no SQL injection is ever possible.

Similarly if HTML was strongly typed and you didn't write a HTML string out to the browser but wrote an AST out then XSS wouldn't exist. Silverlight might be dead, but it never had XSSes for the simple reason that nobody in their right mind would try to dynamically build a Silverlight app on the fly and glue attacker controlled strings directly into the code.

If your data never went into the filesystem as a typeless blob next to your code, but rather went fully typed into your database, then arbitrary uploads wouldn't exist either.

My point is that you get better security by having stronger types. Dynamic languages decouple unit and security non-composability requirements tests from your code, and too many developers don't have them, but have them separate  They just don't have them, leading to worse and less secure code.