-
Notifications
You must be signed in to change notification settings - Fork 184
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
Make writeable_cmp_bytes a free function #5737
Conversation
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.
good call
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 don't think this simplifies. There writeable argument is kind of fundamental so I think this should be a method.
The trait should only have things that can actually be specialized. Defaulted trait functions create maintenance burden and code bloat. I want to move more toward free utility functions (#5738). |
I agree on avoiding exposing functions like this for overriding |
Note that the |
I think a free function is good, but if you don't like the ergonomics, it could be added by trait injection pub trait WriteableCmpBytes {
pub fn writeable_cmp_bytes(...)
}
impl<T: Writeable + ?Sized> WriteableCmpBytes for T { ... } But I prefer free functions. |
Additional context: I had originally made this a function on the trait because I had thought that it could be specialized for certain types. However, a year in, we haven't found cases where a concrete type can offer a more efficient implementation of this function than the default, according to the benchmarks in this PR. So, there is no longer a technical reason why it needs to be a trait function. |
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.
Ok I buy the consistency argument. It would be nice if Rust had final trait methods for things like this (I think we discussed this at Rust conf at some point?).
utils/writeable/benches/writeable.rs
Outdated
@@ -72,7 +72,7 @@ writeable::impl_display_with_writeable!(ComplexWriteable<'_>); | |||
|
|||
const SHORT_STR: &str = "short"; | |||
const MEDIUM_STR: &str = "this is a medium-length string"; | |||
const LONG_STR: &str = "this string is very very very very very very very very very very very very very very very very very very very very very very very very long"; | |||
const LONG_STR: &str = "this is a very very very very very very very very very very very very very very very very very very very very very very very very long string"; |
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.
this change seems unnecessary and invalidates benchmark history.
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 thought a longer overlap would make more meaningful benchmarks for cmp_bytes
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.
Maybe we rename the benchmark, or have LONG_STR_DIVERGE_EARLY and LONG_STR_DIVERGE_LATE
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 thought a longer overlap would make more meaningful benchmarks for cmp_bytes
And it totally is. Just use a new const for it so all the preexisting benchmarks are kept stable.
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 don't really see the problem to be solved (the new string is only 2 bytes longer than the old one, and people who track the benchmarks over time can see this commit as the culprit) and prefer merging this as-is but I can make @Manishearth's suggested change if necessary.
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.
people who track the benchmarks over time can see this commit as the culprit
If you're looking at the graph you don't know whether it's a benchmark setup change, or a behaviour change. All you'll see is "Make writeable_cmp_bytes a free function", which shouldn't change any benchmarks.
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 made the string the same length as before. (The bigger change requires a setup with a code editor which I don't have at the moment but will in about an hour.) I still prefer landing this to avoid the context switch later.
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.
ok I didn't hear back about whether my compromise was sufficient so I went ahead and implemented the solution that I believe addresses @robertbastian's blocking concern.
utils/writeable/src/cmp.rs
Outdated
/// | ||
/// This returns a lexicographical comparison, the same as if the Writeable | ||
/// were first converted to a String and then compared with `Ord`. For a | ||
/// locale-sensitive string ordering, use an ICU4X Collator. |
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.
writeable should be independent of ICU4X, not sure we should recommend this here.
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.
+1
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.
This is pre-existing text.
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 changed the text slightly. I recommend to icu_collator
as an external crate that does localized string sorting in the same vein as Jiff might recommend icu_calendar
as an external crate that does non-Gregorian calendars.
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, that works.
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.
Not super happy with this, but won't block the PR as this is preexisting. impl Ord for str
, and str
I guess don't go into locale-aware collation either, and I consider this crate an alternative to those core types.
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.
.
It simplifies writeable impls. There is no impact on benchmarks, either the new microbenchmark I added or the higher-level
strict_cmp
benchmark in the icu_locale_core crate: