-
Notifications
You must be signed in to change notification settings - Fork 176
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
Transliterator is missing compiled data constructors #4890
Comments
Hi @kornelski! Most functions with the large trait bounds have a link to this page which explains what they mean: These bounds are what enable ICU4X to slice the data to exactly what is needed and avoid having a big monolithic data file as is required by ICU4C that doesn't have these bounds. In general you should be using functions like |
Actually I'll re-open this issue specifically for |
Partial fix for the In the short term, you can get the type you need, the one that implements all the trait bounds, like this: include!("tests/transliterate/data/baked/mod.rs"); where It's not ideal that this is in a test directory, which is why I put up #4898. I think this is just an oversight from when we moved the code into the new |
|
The
icu_transliterate
crate has constructor methods that take:This is a large complex-looking trait bound, which does not help me figure out what the actual type is needed here. Even when I try to browse the mentioned types like
TransliteratorRulesV1Marker
, it leads to more levels of abstraction, which all end at someHelloWorldProvider
.As a result, this API is so opaque and overly abstract, that I can't even tell if the transliterator is working at all, or is it a defunct stub that has no real implementations.
Some methods have shockingly large trait bounds. To me this is very discouraging, because I'm afraid that if I run into even slightest problems with this crate, I'll be faced with such wall of abstractions upon abstractions, requiring me to understand an abstraction with over 60 degrees of freedom, which seems absolutely an overkill when there's probably between 0 to 2 actual implementations of it.
The text was updated successfully, but these errors were encountered: