-
Notifications
You must be signed in to change notification settings - Fork 169
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
Store Unicode keywords in ResourceOptions #1750
Conversation
This reverts commit fe2370c.
At first I tried using a straight
New:
I got the size regression down to something I am okay with:
I did this by storing Looking at the assembly, I think the sizes will go down further once we're using Update 2022-04-12: The size on main is now
and this PR changes it to
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, right. Thank you! lgtm
@sffc What's the best way to review this? (Also, I haven't started yet, so if you're able to squash some of the smaller related commits to make it easier to review, would be appreciated) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm overall, just some small things
provider/core/src/resource.rs
Outdated
/// | ||
/// If you have ownership over the `ResourceOptions`, use [`ResourceOptions::into_locale()`] | ||
/// and then access the `id` field. | ||
pub fn langid(&self) -> LanguageIdentifier { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why doesn't this borrow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah we should probably return an &LanguageIdentifier
and let the user clone if they need it; usually common in Rust for the user to have control over that
Till now LanguageIdentifier was expected to be a cheap clone as much as possible so cloning was more okay, but that's also changing with our vertical fallback plans, so i do think we should avoid unnecessary clones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(interpreting this as a Question
)
Mainly because I wanted to stop exposing the internals of ResourceOptions
. I've introduced the following functions:
- This method, which constructs a new
LanguageIdentifier
, which usually doesn't allocate - Direct accessors for the language, script, and region subtags, which never allocate
locale(self)
which moves out ofself
without allocating memory and without exposing the internals directly
I'm willing to discuss this and explore alternatives if you have suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You made another comment but it's not showing up in this thread.
The main reason I don't want to return &LanguageIdentifier
is because I don't want to expose the internals of ResourceOptions. For example, we may consider a change that stores the subtags flat with a single variant, or something else that is hyper optimized for vertical fallback. I expect that most things users would need to do with ResourceOptions should be methods directly on it. It's not the business of the user of this class that we're able to return a &LanguageIdentifier
.
Review notes for @Manishearth:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
praise: i really like this change!
provider/core/src/resource.rs
Outdated
/// | ||
/// If you have ownership over the `ResourceOptions`, use [`ResourceOptions::into_locale()`] | ||
/// and then access the `id` field. | ||
pub fn langid(&self) -> LanguageIdentifier { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah we should probably return an &LanguageIdentifier
and let the user clone if they need it; usually common in Rust for the user to have control over that
Till now LanguageIdentifier was expected to be a cheap clone as much as possible so cloning was more okay, but that's also changing with our vertical fallback plans, so i do think we should avoid unnecessary clones.
} | ||
|
||
/// Returns the [`Locale`] for this [`ResourceOptions`]. | ||
/// |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: doc that this clones the langid and perhaps suggest folks use the proposed-non-cloning .langid()
if they just need a langid
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I updated the docs, and in the process removed this function. There were not many call sites.
Changes in the latest commits:
If any of these changes are controversial, I may revert those commits in order to get this PR landed. |
/// &unicode_ext_value!("coptic"), | ||
/// )); | ||
/// ``` | ||
pub fn matches_unicode_ext(&self, key: &unicode_ext::Key, value: &unicode_ext::Value) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: do we not usually pass tinystrs/subtags by value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the accepted convention is to pass Copy types by value; but there are exceptions both ways. At play here:
- In this case, Key but not Value is Copy. I could pass one by value and the other by reference, or both by reference.
- Many map interfaces pass by reference all the time, even for Copy types.
I don't have a strong opinion.
Part of #1109
This PR changes
ResourceOptions
to have private fields and store a Unicode Keywords object instead of a string. It centralizes the ResourceOptions constructors and leaves TODOs pointing to #1109.