You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently if you want to have a language identifier that is valid at compile time you need to pull the proc macro langid!, which is a pretty heavy dependency in terms of compile times when your only use is langid!("en"). It would be nice if there's was a set of constants available for common language identifiers.
The text was updated successfully, but these errors were encountered:
We added the proc macro exactly to avoid defining limited number of consts. ICU does it and I quite frankly find it weird - it's against the whole philosophy of internationalization to say there's "a common language identifier".
Since I think it's more likely that you'll have a "common language identifier" in your project, I'd first try to figure out what it would take to make it easy for you to define your own const in your library/app. Is there something unic-locale can do to make that easier?
I understand that motivation behind making the proc macro, and not wanting to have preferential treatment. However I think the current situation is quite annoying for my use case which is building higher level libraries and tooling on top of this library rather than a top level application.
When you use a proc macro in your tests and make a change in your crate all of those proc macros need to re-run every time, the only way around this is to move all the proc macro calls into a separate crate so that rust can compile it as a separate code unit.
Having a more limited selection is an acceptable trade off when I’m mainly concerned with testing that my library works with any language identifier.
Having a more limited selection is an acceptable trade off when I’m mainly concerned with testing that my library works with any language identifier.
I understand that sentiment. I'm wondering if there's a way to make it easy for you to implement a const LanguageIdentifier rather than have unic-locale carry it.
Currently if you want to have a language identifier that is valid at compile time you need to pull the proc macro
langid!
, which is a pretty heavy dependency in terms of compile times when your only use islangid!("en")
. It would be nice if there's was a set of constants available for common language identifiers.The text was updated successfully, but these errors were encountered: