-
Notifications
You must be signed in to change notification settings - Fork 165
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
Improve plural operand handling #1091
Comments
@eggrobin Could you take a look at the bullet points in this issue and determine what needs to be done? |
@eggrobin Please take a look at this; thanks! |
Work to be done here:
|
Discussion:
|
Can we make sure to have this as Alternatively, could we have a struct called |
The other option is we just change all call sites to do |
let po = PluralOperands::from(IVWFTC {
i: 2,
v: 1,
f: 1,
t: 2,
c: 0,
}); vs. let mut po = PluralOperands::default();
po.i = 2;
po.v = 1;
po.f = 1;
po.t = 2; vs. let po = PluralOperands::from_ivwftc(2, 1, 1, 2, 0); My vote is on the first. |
The advantage of option 2 is that we don't need any more APIs or experimental features. Between 1 and 3, I slightly prefer 3 because it doesn't involve importing an extra type and calling the less-discoverable From/Into impls; you just invoke the function. |
After discussing with @markusicu and @echeran, the point was brought up that these fields should really not generally be things that users of ICU4X should know about or mutate. I'm therefore heavily inclined to recommend the following:
|
My vote is |
|
What to do next:
LGTM: @sffc @zbraniecki @markusicu @echeran |
In case we're not already doing it, we should make sure that when parsing a string representing a number and/or performing
PluralRules::select()
:c
operand from thee
operand, to future-proof when those behave differentlyThe text was updated successfully, but these errors were encountered: