Skip to content
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

Add common LanguageIdentifier consts #62

Open
XAMPPRocky opened this issue May 22, 2020 · 3 comments
Open

Add common LanguageIdentifier consts #62

XAMPPRocky opened this issue May 22, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@XAMPPRocky
Copy link
Contributor

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.

@zbraniecki
Copy link
Owner

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?

@zbraniecki zbraniecki added the enhancement New feature or request label May 24, 2020
@XAMPPRocky
Copy link
Contributor Author

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.

@zbraniecki
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants