On 22/09/14 03:21 PM, Chris Morgan wrote: >> It's completely unnecessary actually. > Would that it were. There was a time when I believed it was, but it's not. > >> If a method requires a XSS-safe string, then it should take the > XssSafeString parameter, which would implement Deref<String> and would > be built from a String by a method performing the necessary escaping. > This sort of thing is the idea—building it all into the type system is > the goal. The question was to do with getting around that, doing > something that would *not* be safe. You can build as great a library > with the type system as you like, but eventually someone will want—nay, > need—an escape hatch. Perhaps they are dealing with a legacy system > that, alas, requires broken behavior; or perhaps a performance issue > with the normal way of doing it needs to be circumvented. This part, > breaking the rules in a reasonable manner yet without it being so normal > that everyone does it (*cough* PHP *cough*), is the part that was being > discussed at that point. > > I consider `unsafe` to be entirely justified here because we're dealing > with data being able to break the invariants of the type. If, for an > arbitrary example, we have an HTML chunk we are going to emit and wish > to insert something known to be legal HTML as we emit it, there are > shortcuts that can be taken. But if it was not in fact legal HTML, the > invariants of the type are broken and the interpretation of the data no > longer certain. Thus it should be marked image, just like the UTF-8 > constraint of strings.
Rust doesn't use `unsafe` to uphold the UTF-8 invariant of strings. It uses `unsafe` as a memory safety boundary, and in this case breaking the invariant would be memory unsafe.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
