3 ms·

Imagine if even strongly typed languages had different string types for various encodings like that and enforced them. Then such bugs would be as rare as, say,

Imagine if even strongly typed languages had different string types for various encodings like that and enforced them. Then such bugs would be as rare as, say, a date appearing as a huge integer.

rhn_mk1 4y ago
When Python did that to separate raw bytes and proper Unicode, people pointed this out as a reason they don't want to use the language any more.
- sacrosancty 4y ago
  Sounds like Python wasn't right for those people in the first place. Abstracting away the internal data format is typical of Python.
Thorrez 4y ago
https://angular.io/api/platform-browser/SafeHtml https://angular.io/api/platform-browser/SafeHtml https://google.github.io/closure-library/api/goog.html.SafeHtml.html https://google.github.io/closure-library/api/goog.html.SafeH...
Cu3PO42 4y ago
To a degree, Rust does this. The standard string type is always guaranteed to be valid UTF-8. Then there's a string type for the OS native format and a string type for what constitutes a valid path on the file system. Of course, arrays of bytes also exist and so does a type for a null-terminated "CString". Converting between them requires runtime checks (unless you invoke unsafe code and promise you know better than the compiler). It's cumbersome at times, but a perfectly reasonable tradeoff in my opinion. Some libraries add other string types when they're needed to interact with a system. For example, the windows crate has wide strings.
notacoward 4y ago
There was a research C compiler, maybe related to the meta-compilation effort that became Coverity, that did something like this. It let you attach arbitrary attributes to a variable and then enforce invariants regarding those attributes. The one that caught my eye was tagging checked vs. unchecked user input, so that using such input before checking (or sanitizing) would become a type error. It's a shame that the idea didn't catch on more.
mejutoco 4y ago
This is a good idea I believe. While I agree it would be convenient to have it in the standard library of more languages, it can be implemented in strongly typed languages, using something like Newtype in haskell. In Typescript, for example, it could be: type SanitizedString = string And somewhere you have a function getSanitizedString and if you don't call that the type system will complain. Same could be done to represent a distance in Km or miles: type DistanceKm = number type DistanceMiles = number And then functions can explicitly use any of them or only some (we could define some function multiplying them to allow 2 arguments only if they are the same type).

Imagine if even strongly typed languages had different string types for various encodings like that and enforced them. Then such bugs would be as rare as, say, a date appearing as a huge integer.

rhn_mk1 4y ago

When Python did that to separate raw bytes and proper Unicode, people pointed this out as a reason they don't want to use the language any more.

sacrosancty 4y ago
Sounds like Python wasn't right for those people in the first place. Abstracting away the internal data format is typical of Python.

Thorrez 4y ago

https://angular.io/api/platform-browser/SafeHtml https://angular.io/api/platform-browser/SafeHtml https://google.github.io/closure-library/api/goog.html.SafeHtml.html https://google.github.io/closure-library/api/goog.html.SafeH...

Cu3PO42 4y ago

To a degree, Rust does this. The standard string type is always guaranteed to be valid UTF-8. Then there's a string type for the OS native format and a string type for what constitutes a valid path on the file system. Of course, arrays of bytes also exist and so does a type for a null-terminated "CString". Converting between them requires runtime checks (unless you invoke unsafe code and promise you know better than the compiler). It's cumbersome at times, but a perfectly reasonable tradeoff in my opinion. Some libraries add other string types when they're needed to interact with a system. For example, the windows crate has wide strings.

notacoward 4y ago

There was a research C compiler, maybe related to the meta-compilation effort that became Coverity, that did something like this. It let you attach arbitrary attributes to a variable and then enforce invariants regarding those attributes. The one that caught my eye was tagging checked vs. unchecked user input, so that using such input before checking (or sanitizing) would become a type error. It's a shame that the idea didn't catch on more.

mejutoco 4y ago

This is a good idea I believe. While I agree it would be convenient to have it in the standard library of more languages, it can be implemented in strongly typed languages, using something like Newtype in haskell. In Typescript, for example, it could be: type SanitizedString = string And somewhere you have a function getSanitizedString and if you don't call that the type system will complain. Same could be done to represent a distance in Km or miles: type DistanceKm = number type DistanceMiles = number And then functions can explicitly use any of them or only some (we could define some function multiplying them to allow 2 arguments only if they are the same type).