On 13-07-28 09:24 PM, Alex Crichton wrote:
I would love comments/suggestions on this system. I think that this takes into
account almost all of the feedback which I've received about how formatting
strings should work, but extra sets of eyes are always useful!
In general I'm really happy you're taking this on. Hopefully you've been
able to recycle bits of code from https://github.com/Aatch/rust-fmt or
at least chat with Aatch, Huon and Kimundi about it?
Some comments:
- There are six CLDR pural keywords, not five: there's also 'other'. You
use it in your examples but not in the grammar given.
- I don't see how the example {:date} is generated from the grammar.
Though I do think custom (especially culture-specific) formatter
functions do need some support. Money and dates are the big two.
- I agree with others that the formatting of decimal has wiggle room in
the design; python's choice is ... so-so? C# has a version[1] that
includes culture-specific hooks for number formatting and fairly
extensive control over individual axes of formatting. You should
probably also spend a little while digging through the way C++
locales and facets work[2]. Possibly try to get Nathan Myers into
the conversation (he's on this mailing list) as I believe he designed
that system. The second link in [2] is to his site.
- I also agree with Brian that _generalizing_ format modifiers somewhat
(so that formatting options can pass from format-string through to
formatter) might be worth thinking about some more. It's related to
the previous point, in the modifiers-for-numbers case. Can we pass
modifiers for strings? (width, case, justification?) how about
iterators (common lisp supports formatting sequences, the specifier
takes a separator as a formatting option[3]) or tabulation (also
in CL[4])? All this is a bit overkill for most formatting; but I
wonder if we'll find ourselves in a position in a few years of
thinking "formatting would be great if only there was a switch for
$THING" and the mechanism for adding switches was set a bit too
much in stone.
- Your implementation is extremely clever and appears to be low
overhead, which is _great_. I am a little saddened, though, that
it rests not just on something that can dynamically fail but that
can (presumably) fail _badly_ (memory unsafe?) if called wrong.
I wonder if there's any sort of trickery to make the innermost
fprintf function memory-safe, just dynamically fail on bad args.
I can think of a number of ways of approaching that using &Trait,
enums of the different format strings, visitor methods, etc. Not
sure which would be best. I don't wish to diminish the cleverness
of your approach; making the innermost function memory safe would
just be icing on the cake.
But these are mostly minor nits, nothing to talk you out of it. I think
you're on the right track. Thanks again for digging into it.
-Graydon
[1]
http://msdn.microsoft.com/en-us/library/system.globalization.numberformatinfo.aspx
[2] http://stdcxx.apache.org/doc/stdlibug/VII.html
http://www.cantrip.org/lib-locales.html
[3] http://www.lispworks.com/documentation/HyperSpec/Body/22_cgd.htm
[4] http://www.lispworks.com/documentation/HyperSpec/Body/22_cfa.htm
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
