I really think parse don't validate gives people a false sense of security (particularly false in dynamic languages like javascript and python).

"Well, I already know this is a valid uuid, so I don't really need to worry about sql injection at this point."

Sure, this is a dumb thing to do in any case, but I've seen this exact thing happen.

Typesafety isn't safety.

▲

yakshaving_jgt 3 days ago | parent [-]

Type safety is absolutely some degree of safety. And I don’t know why anyone would think parsing a value into a type that has fewer inhabitants would absolve them of having to prevent SQL injection — these are orthogonal things.

The quote here — which I suspect is a straw man — is such a weird non sequitur. What would logically follow from “I already know this is a valid UUID” is “so I don’t need to worry about this not being a UUID at this point”.

▲

jappgar 3 days ago | parent [-]

In python or typescript, the most popular languages in the world, it offers no runtime safety.

Even in languages like Haskell, "safety" is an illusion. You might create a NumberGreaterThanFive type with smart constructors but that doesn't stop another dev from exporting and abusing the plain constructor somewhere else.

For the most part it's fine to assume the names of types are accurate, but for safety critical operations it absolutely makes sense to revalidate inputs.

	▲	yakshaving_jgt 3 days ago \| parent [-]
		> that doesn't stop another dev from exporting and abusing the plain constructor somewhere else. That seems like a pretty unfair constraint. Yes, you can deliberately circumvent safeguards and you can deliberately write bad code. That doesn't mean those language features are bad.