Thanks for all the comments everyone! I'll see if I can address a good
number of them here:
> - 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.
At the end of the format spec a `type` could be any identifier. I
wanted to make multi-char identifiers possible because `:date` makes a
lot of sense just reading it to see what it does. I also believe that
because the formatting is trait-based, it should be easy to implement
something like `idate` and `imoney` for the internationalized versions
in a library. I believe though that this is definitely possible!
> - I agree with others that the formatting of decimal has wiggle room in
> the design; python's choice is ... so-so?
I agree, I think that the way I want to go now is to implement the
formatting specifiers in whatever syntax seems natural at first, and
then before we start converting everything over to the new formatting
system take some time to bikeshed the syntax of this. The syntax
itself will be pretty easy to change along with the formatting
routines at the beginning. I'm going to try to get most other stuff
working first before tackling the specific syntax though (if that's
ok).
> - 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.
One cool thing that python does is allow `{:%d/%m%y}` for formatting
dates. I agree that it's an awesome ability and has some really cool
potential. The downsides to this are that the format string can't be
checked at compile-time, and you may still want to specify alignment
and things like that. Good news is that this is probably pretty easy
to deal with (like the decimal format syntax) once all the rest of the
infrastructure is in place.
> - 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?)
I think there might be some cleverness that could happy with TyDesc
objects, but that would result is something like a static array in
each executable with a mapping from "string format name" to TyDesc
object. I do agree that this would be nice to have, though, because I
was similarly saddened when I realized that I would have to flag the
function as unsafe.
> keyword/named selection is *really* great for longer/more busy patterns
I agree that this would be nice to have, and I think that Huon's
suggestion is a fantastic one! I'll try to target the `fmt!("{foo}",
foo=bar)` syntax to start out with.
> Can we have both? Parse at compile time if the string is constant but parse
> at compile time if the string comes from something like a gettext-ish
> function that loads the string from a message catalog.
I can imagine a system where we do have both. One difficult part of
this is that I wanted the runtime cost at the callsites to be as small
as possible (with the goal of reducing codegen size). Precompiling
this into something which doesn't result in massive codegen is a
difficult problem that I was having a lot of trouble figuring out how
to do. One thing I wanted to do in the long term was to implement
purely runtime-based parsing, benchmark it, and then toy around with
various precompiled versions to see how much the actual speedup is. If
there's a noticeable 3x speedup, then it's probably worth the extra
code overhead, but if it's like 10% it may not be as worth it.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
