On 13-07-14 11:30 PM, Jack Moffitt 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 didn't suggest we remove fmt!, but that we make the default println!
> not do formatted output by itself. My motivation is to make the tool
> you reach for first solve 80% of the use cases and be as simple as
> possible.
Ok. Maybe we / I misread. I was responding to this:
"Do away with the formatting stuff as the default."
"change code like this: println!("The result is %f", foo);
to this: println!("The result is", foo)"
These sound like they're ... in the wrong spirit, to me. Obviously some
output should be un- or lightly-formatted (logging, diagnostic, raw-data
output, json, tabular stuff, etc.) but that's a linguistic example that
looks like it's intended for an end-user. That's the primary case for
l10n-friendly format strings. I don't want to be nudging any users away
from l10n-friendly by default in cases like that; I want to be nudging
them _towards_ l10n-friendly.
> Support for i18n is a great thing, and I hope we provide it out of the
> box, but it's a lot more complicated than printfln(). Do we want that
> complexity in the basic print function? If so, what are the proposals
> for managing that complexity?
It's not a _lot_ more complicated than printfln(), no. It's a little
more, in the sense that handling leapseconds is a little more complexity
than not, and handling UTF8 is a little more complexity than handling
ASCII. But I don't think that means we get to ignore them. And I think
they're better dealt with sooner than later.
In C programs gettext has got it down to printf(_("my name is %s"), x).
Gettext and printf are known to be inadequate but in ways mostly
addressed by Java and later CLDR/ICU-style messageformat strings[1][2]
which have a similarly benign interface to the programmer, and that
similarly reduce the problem to "what mini-language you support in the
format strings". So the proposal I have put forth in previous threads,
which I'll repeat here, is "best current practice with message
catalogues", which means:
- .po files (the tools for managing strings are familar / loved)
- format strings with nestable {n} placeholders rather than
non-nesting %-placeholders, and simple conditional forms borrowed
from the work Java and ICU/CLDR have done in this field.
For tracking work, I refer you to bugs:
https://github.com/mozilla/rust/issues/4630
https://github.com/mozilla/rust/issues/2249 (metabug)
New format library sketch:
https://github.com/Aatch/rust-fmt
Mailing list thread messages I posted on it:
https://mail.mozilla.org/pipermail/rust-dev/2013-May/004064.html
https://mail.mozilla.org/pipermail/rust-dev/2013-May/004086.html
https://mail.mozilla.org/pipermail/rust-dev/2013-May/004093.html
https://mail.mozilla.org/pipermail/rust-dev/2013-May/004100.html
Not-very-fleshed-out library-work page pointing to prior art:
https://github.com/mozilla/rust/wiki/Lib-fmt
I'm happy to have people look into this, it needs to be done (and is
actually a cost center in our current code). It falls in the same bucket
as the IO library as a surface-UI thing that is very high visibility,
early-contact, and must be Done Right before we finalize APIs / commit
to backwards compatibility. But I want to make it l10n-friendly by default.
> As an addendum, I think debug! and friends should work similarly. I'll
> also note that there's no debugln! and I haven't seen any complaints
> about that. having debug! and debugf! seems reasonable if people
> really feel strongly that they need formatted output in printf style.
Yeah, the \n / ln / fln thing is a red herring. I'm fine with all such
variants existing, and for debugging / logging to hit the unformatted
path. They're perf critical[3].
-Graydon
[1] https://github.com/SlexAxton/messageformat.js
[2]
https://docs.google.com/presentation/d/1ZyN8-0VXmod5hbHveq-M1AeQ61Ga3BmVuahZjbmbBxo/pub
[3] (Concerning perf: there's a reasonable sub-argument in here that
static compilation of a format string to a sequence of
format-trait-calls is going to carry a major perf advantage over _any_
runtime interpretation. I think this is a very subtle balance to get
right if we want to support runtime .po-string loading, and minimize
code bloat on cold code paths caused by format strings. It may require
careful measurement and some combination of cached runtime-compilations
and &Trait / vtbl dispatch. Or it might be something we have to surface
to the user, how they compile-down a format string. I think it's similar
to the set of issues we'll encounter when doing a regexp library.)
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
