Skip to content
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

Open
ogoffart opened this issue Nov 25, 2018 · 1 comment
Open

RFC: design of the tr! macro #1

ogoffart opened this issue Nov 25, 2018 · 1 comment

Comments

@ogoffart
Copy link
Member

Syntax

Current syntax:

tr!("Hello", ...args... )
tr!("ctx" => "Hello", ...args...) // with '=>' for context
tr!("one Hello" | "{} Hello's" % count, ...args...) // plurals with '|' and '%'
tr!("ctx" => "one Hello" | "{} Hello's" % count, ...args...) // context and plural

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 the count variable before the string, but
that makes the macro difficult to parse because only some token are allowed after an expr in a macro, and => was already taken for the context

Another possibility could be, for example

tr!("ctx" @ count => "one Hello" | "{n} Hello's", ...args...)

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 allow

  • to save one memory allocation in case the string is only used within another format!
  • better error reporting, maybe (that the format was incorrect, or that the string was not translated)

Maybe 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.

@ogoffart ogoffart changed the title RFC: desing of the tr! macro RFC: design of the tr! macro Nov 25, 2018
@hellow554
Copy link

hellow554 commented Jan 21, 2019

First off, cool project!
Second, my two cents:

tr!("one Hello" | "{} Hello's" % count, ...args...) // plurals with '|' and '%'

I do understand, why you choose the syntax, but it's very unrusty. It's more pythonic. The best would be to append the count variable to args, but I'm afraid that won't work either (both literals have to use all parameters). I guess your second approach is better, although more verbose

tr!("ctx" @ count => "one Hello" | "{n} Hello's", ...args...)

One could extend this to an actual match case, so you can specify when to use the plural form and when not.

What should be the type of the tr! expression

I guess a Cow<str> would fit best here, because it is possible, that it will return the &'static str, or a String, when it has been actually formatted.

The question is what to do when the formating contains error

Return a Result<Cow<str>, FormatError> (with FormatError being a custom error type). That is the way to go! You can always use the ? operator as a shorthand version. It's the cleanest, possible way IMHO.

And perhaps showing an error on stderr could be done

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 Result or using https://crates.io/crates/log)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants