4 ms·
This is "parse, don't validate" as a language feature. Any statically typed language has this, in the sense that you can write your domain logic in terms of a s
by kqr 1y ago
This is "parse, don't validate" as a language feature. Any statically typed language has this, in the sense that you can write your domain logic in terms of a set of "untainted" domain types, and only provide safe conversion functions (parsers) from user input to domain types.
- layer8 1y agoNo, they really don’t have this, because for example you can still open() using an arbitrary string as a file name, a string which may have come from unvalidated input. They don’t force you to convert the string to a FileName type and also prove that you have done some sort of pattern-matching on the string.
- kqr 1y agoThat is true. You'd need to expose alternative versions of system functions that deal only in parsed and not raw data, and then prohibit the native variants. A little more ceremony, but also a little more flexibility. Edit: It might be easier to instead replace input functions with ones that return TaintedString, unusable as a regular string. But it's easier to write a linter rule that prohibits any unsafe (default) system functions than one which requires safe input functions, I suppose.
- kstrauser 1y agoNow I’m imagining a Rust UncheckedString type with a to_string() method that takes a regexp.