Just looking at the safe/unsafe string example I wonder if another usable approach would be to ditch plain strings and instead use thin wrappers like UnsafeString and SafeString and a bunch of operations on them. But not assignment, for instance.
There wouldn't be much need to care about whether the code looks wrong or not (welll with regards to safe vs unsafe string:), because the compiler would do it for you (or runtime I guess, depending on which laguage it gets implemented in). I think all the examples Joel writes (the ones 'xxx is always ok' and 'xxx is not ok') are covered by it. It does mean you need a Write which only takes SafeString I guess, and it probably doesn't mean you can still do something wrong, but it should be much harder.
I had a similar thought- Rust has "tuple structs" which are effectively structs without property names. You could make singletons:
struct Relative(i32);
struct Absolute(i32);
let foo = Relative(12);
let bar = Absolute(12);
fn useAbsolute(coord: Absolute);
useAbsolute(foo); // Err!
and effectively get this idea enforced at the type level. Of course support for this pattern would vary by language, and there would probably be some small overhead, but it could be worth it.
This is my #1 complaint with static type systems. Static typing advocates say they allow the compiler to check for correctness, but all these type systems are only the thinnest possible wrappers on machine types.
An HTML-escaped string is not at all the same type as an untrusted user-entered string. They just happen to both be represented by a sequence of characters. An integer that represents my age in years is not at all the same type as an integer that represents my height in centimeters. They just both happened to be represented by a 64-bit two's-complement integer (probably).
The fact that the underlying physical machine types match is not helpful in determining whether it makes sense to add or concatenate these. (If anything, it provides a false sense of security.) The most advanced programming languages on my computer are still worse at dimensional analysis than a middle school kid with a pencil.
I'm starting to play around with a new type system to remedy this. I don't have a programming language for it yet, though.
I fully agree that the types offered by the programming language (wrapping the underlying types) are not enough. However, a static type language allows you to define your own types. So (as your sibling comment by brundolf suggests) you can create your own types around the existing types such as HtmlEscapedString and UntrustedUserEnteredString. The syntax is particularly convenient in Rust, but you can do the same in e.g. Java, or any other statically typed language, albeit more verbosely:
This is one of those "Turing tar-pit" scenarios. As you point out, it's technically possible, but in most languages, it would drastically increase the verbosity of the code.
None of the built-in control structures will work with your custom types. In Java, for example, "int" is a primitive, and "Integer" is final. All the built-in functionality that works with numeric types won't work with your types. All of the standard and third-party libraries expect the built-in types, too. Java doesn't support operator overloading, so you wouldn't be able to + your numbers, either. Instead of helping you with every arithmetic operation, it would be a massive pain point at every arithmetic operation.
Strings and integers are fundamental types. Programming languages just aren't designed to let people substitute their own.
There wouldn't be much need to care about whether the code looks wrong or not (welll with regards to safe vs unsafe string:), because the compiler would do it for you (or runtime I guess, depending on which laguage it gets implemented in). I think all the examples Joel writes (the ones 'xxx is always ok' and 'xxx is not ok') are covered by it. It does mean you need a Write which only takes SafeString I guess, and it probably doesn't mean you can still do something wrong, but it should be much harder.