4 ms·

So, does that mean every string's { need to be doubled to {{? Doesn't that open a big security hole where someone could inject a special string to probe for va

• jhugo 5y ago
  No, this is functionality of format strings (interpreted by the formatting macros like println!, format! etc), not strings in general. {} was already special in format strings, there's no backward compatibility break. You can't really pass untrusted input as a format string because they have to be available at compile time.
  • joss82 5y ago
    OK, thanks for explaining that point :). I was expecting this but couldn't find it in the doc nor the release notes.
  • Someone 5y ago
    So, that rules out using format strings read from configuration text files. Not a big loss, IMO (you can have a DE.rs file with format strings for German, an IT.rs one for Italian, etc. and compile those in the binary), but I think some organizations will find that inconvenient. Also, FTA: “Remember that Rust doesn't use any localization, so these outputs will always look the same.” So, what do rust programs do for localization, e.g. to print the thousands separators users expect? Is there a library that gives you similar string interpolation, taking locale into account? It’s a tough call between catering for computers by ignoring locale and for humans by applying it, but I think I would have chosen for this to be locale-sensitive, with support for forcing a standard locale.
    • zaarn 5y ago
      There is a few libraries that can do some work around localization and formatting, though IIRC most commonly if you need something translated, you just turn it into a format argument as well. So instead of say "hello {name}", you write "{greeting} {name}" (though this doesn't cover all languages anyway). edit: There is also the issue that on some platforms (Linux) locale has some soundness issues (not a fault of rust) and yet on others it can be hard to use locales properly (Windows can introduce some hard locale weirdness)
      • Someone 5y ago
        That doesn’t work if you have to change word order. A format string {a} foo bar {b} Might have to be translated as Baz {b} {a} quux (Also notice that, in the first sentence, you might want to capitalize {a}. That’s complicated in itself. Localization is a rat’s nest. I don’t think you can expect any automated system to do it perfectly)
        • zaarn 5y ago
          I've already mentioned this won't cover all languages.
    • jhugo 5y ago
      https://github.com/projectfluent/fluent-rs https://github.com/projectfluent/fluent-rs is some interesting work in this direction.
    • japanuspus 5y ago
      The reasoning behind the rust approach: - As pointed out by GP, `format!` is a macro and only works for literal format strings available at compile time. This allows the compiler to convert the format string to code _at compile time_. - What you are talking about is a general string template/formatting engine to execute at runtime. Such a feature can easily be provided by external crates, because it would work at runtime and not require any particular interactions with the compiler.
    • Karliss 5y ago
      Using generic printf/format like function for localization is a bad idea anyway. Proper localization libraries have features like handling of plurals. Nothing prevents a localization library from creating it's own formatting function, which it would have to do it anyway since the formatting syntax for each of commonly used localization file formats (po,xlif,ts, ...) likely differs from format function in the programming language X.
    • vintermann 5y ago
      Things that change unexpectedly because of locale would be a far more serious problem for Rust than lack of automatic default localization attempts. "Things breaking because of unexpected locale issues" is pretty high up on the most common bugs list.
    • dragonwriter 5y ago
      > So, that rules out using format strings read from configuration text files Rust already used curlies to indicate places where values would be inserted in format! (including print!/println!) strings, so you couldn't use them from config files with unescaped curlies already, AFAIK.
      • dllthomas 5y ago
        I think it's the compile time formatting that rules out "using format strings read from configuration text files".