>To take a high-profile recent case: this would do nothing to prevent padding oracle attacks. Or future crypto attacks using techniques unknown to us now I don

>To take a high-profile recent case: this would do nothing to prevent padding oracle attacks. Or future crypto attacks using techniques unknown to us now I don't think it is good argument against preventing known errors. >Your DB could hold people's credit cards in clear-text; how will this language prevent that from happening? You should specify that credit card information should be encrypted. For example, you define type "data CText value = ..." and two functions: "encrypt :: Key -> value -> CText value" and "decrypt :: Key -> CText value -> value". By requiring that certain table contains column of type "CText CreditCardInfo" you will be certain that you used "encrypt" and you won't mix your data with "CText Password". Actually, TDD acronym can stand for Type Driven Design. And as you design your code around tests, you can design your code around types. The main difference is that logic errors will show up earlier and these typed invariants are proven, not tested. So if you add another parameter to your cipertext data type, make it "CText algorithm value", change encrypt and decrypt to "encrypt :: Key algorithm -> value -> CText algorithm value" and "decrypt :: Key algorithm -> CText algorithm value -> value", you can require that that credit card info column should be "CText AES CreditCardInfo". You or your fellow programmer will be forced to provide that. And you won't succeed with ROT13 here.