Delete libextra::unicode

[pzol]

The current code contains a binding to libicu with only is_upper and is_lower implemented, which are already implemented in libstd

/cc @cmr

[kud1ing]

I think it has never been used fully, because noone wanted the additional, heavy dependency on libicu for all Rust code. The story might be different, when this stuff got split off to something like a "libunicode".

[pzol]

And what should go into libunicode? All the unicode tables from
std::unicode + multibyte handling?

On Thu, Feb 27, 2014 at 8:18 AM, kud1ing notifications@github.com wrote:

I think it has never been used fully, because noone wanted that
additional, heavy dependency.
The story might be different, with a split to something like libunicode.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12576#issuecomment-36216887
.

Piotr Zolnierek

[brson]

The existing module can go, but we do need to do something with libicu bindings. Since ICU is so big we might want to give it its own crate, then put our own unicode APIs into libunicode.

[pzol]

What would you envision for libunicode?

I'd rather name it libi18n and place there all stuff concerning localization and internationalisation. It could start as you say as a binding to libicu, but with a much more friendly api.

The unicode tables for case folding, grapheme clustering should imo go into std::unicode.

So I would suggest to place unicode in libstd and internationalisation in libi18n or another similar name suggesting it's purpose.

Piotr

On 28 lut 2014, at 03:58, Brian Anderson notifications@github.com wrote:

The existing module can go, but we do need to do something with libicu bindings. Since ICU is so big we might want to give it its own crate, then put our own unicode APIs into libunicode.

—
Reply to this email directly or view it on GitHub.

[brson]

@pzol I'm afraid I don't know enough about internationalization and localization to know what the right thing to do is, but I'm very keen to find out. Anything non-obtrusive must be better than what we are doing right now.