-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: design of the tr! macro #1
Comments
First off, cool project!
I do understand, why you choose the syntax, but it's very unrusty. It's more pythonic. The best would be to append the
One could extend this to an actual match case, so you can specify when to use the plural form and when not.
I guess a
Return a
Please no :) A library should not print out anything on stderr. You can maybe do that in a C-Library, but Rust has way better ways in dealing with that kind of stuff (e.g. by utelising a |
Hi! This seems like an interesting project! One way of improving memory efficiency while keeping the simplicity of calling `tr!("message") and getting a string could be to provide a family of macros like those in the standard library.
Would the extra first argument to |
Syntax
Current syntax:
I chose the oprator
=>
,|
and%
because out of all possible operator or keywords, this was what seemed to me the most logical. I was considering puting thecount
variable before the string, butthat makes the macro difficult to parse because only some token are allowed after an
expr
in a macro, and=>
was already taken for the contextAnother possibility could be, for example
But
@
is a bit more alien. Or maybe that'd actually be better?(other possible contex separator itoken includes
;
,#
or$
, or maybe keywords)Other suggestions are welcome.
Return Type
What should be the type of the tr! expression? Currently it is a
String
, which is probably the easier to use. Alternatiely, this could be a type whiwh could be implementing Display and possibly other trait, it would allowMaybe another macro name could be used, or a keyword inside the macro to vary the return type.
Formating
If we want to support translation script based on the argument, we need to have the arguments within the same macro. I think it is better to have the same formating as the format! macro, as everybody is familiar with that (currently, not everything is implemented, but that can be solved).
The question is what to do when the formating contains error. Panicing is not a good idea, as we do not want to crash the program when a translation is invalid. Returning an error is not making the all site convininent. So I currently try to make best effort to recover. And perhaps showing an error on stderr could be done.
The text was updated successfully, but these errors were encountered: