On 13-07-14 10:16 AM, Daniel Micay wrote:
Without format strings as the primary way to do output, I think we'll
fall down really short on the ability to do internationalization.
I agree. I18n requires the ability to switch around parameter-order
substantially across a large-ish (sentence-sized) chunk of text; doing
it clause-by-clause doesn't work.
It depends if you're talking logging or user-visible stuff.
Logging by "dumping a sequence of unprocessed values" is definitely
fastest, and I'd be happy to make the simplest variants of log!() or
GLOBAL_LOG.put() or whatever assemble values in memory without
formatting, without i18n, without anything clever. Indeed, logging can
often get by tacking fixed-size entries like a 2-3-word enum onto a log
buffer with pointers to numbers, timestamps, static strings and such.
Many logging systems do this.
But for the user-visible output, console output or UI messages or such,
I want to move us towards an i18n-friendly-by-default style. It's just
running up technical debt for everyone to defer that indefinitely.
I agree that a things like the current %?, or a {n} style format
placeholder that calls "default representation" on any parameter will
continue to be helpful. It should do so statically though, not via the
current visitor mechanism. The whole thing needs to be rewritten to use
traits (and to not allocate, and to target IO streams).
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
