Revisiting no_std in ICU4X

[sffc]

2021 follow-up to #77

The allocator remains one of the largest chunks of code size in WASM files, and it has been reported to us by some customers (such as .NET) that it can cause integration issues.

I would therefore like us to revisit no_std as a baseline in ICU4X, meaning no allocator (more specifically, types that require heap allocations, like Vec and String, would be off limits from core library code).

With #78 and #667, the data provider will support zero-alloc. We are fairly close in some other areas. FixedDecimal and LanguageIdentifier both have a Vec-like field; we would need to decide what to do with these: perhaps return an error code if overflow would occur?

Most importantly, I don't want to embark on no_std without the full support of the team. I truly think no_std is an achievable and noble goal for us, but it will require commitment and a team culture where no_std is the norm. More specifically, although I don't think it should be a requirement that everything in the ICU4X core library is no_std, I want that to be the exception, not the rule. New features should land with no_std support by default, unless team members provide a technical justification otherwise.

[dminor]

There's a little bit of use of Vec in LocaleCanonicalizer, but that is largely driven by the Vec like field on LanguageIdentifier. There's also a use of String to work around some awkwardness parsing an extension value. I think a little work on the APIs for LanguageIdentifier/Locale and it would be easy to remove this stuff.

In general, I think supporting no_std is a good idea. Beyond WASM, it would potentially open up uses in embedded systems as well.

[sffc]

• @zbraniecki - I like the idea but I'm a bit concerned about the drag factor. It's one more thing that affects our velocity. And it's not something we need for Gecko. I think the reward is there, but I'm not sure about the RoI.
• @Manishearth - Now that we have ZeroVec, I think this is a valid goal. Note that trait objects over FFI require allocation because of boxes. So I think this is a good idea, but there are also other ways to solve the C# issues mentioned above. I am in favor of this, but not for the stated reasons.
• @nordzilla - If FFI requires it, then would the only consumers of no_std be Rust consumers?
• @Manishearth - We could do opaque stack traits, but those are tricky. Plugging in a bump allocator would be easier.
• @sffc - I think we can decouple the FFI problem from no_std in components.
• @Manishearth - I think we can do this in many small steps.
• @sffc - We should have a common location where we document decisions about how to migrate things like Vec and String to no_std.

[sffc]

Next step: assess the work involved and find an assignee.

[gregtatum]

praise: Thanks for leaving nice notes on the conversation here, it helps get up to speed here, since I missed this meeting.

[Manishearth]

I'm planning to spend the next week-ish trying stuff here. My initial direction will actually be to have both no_std and no_std-but-alloc support where possible, and perhaps that goal will be too lofty, but I'd like to start with that and downgrade to no_std-with-alloc if it doesn't work. My main goal is to figure out what challenges are involved and how much work this will take. I'm aware of the shape of the challenges for this kind of refactor; however it's as of yet unclear if they apply to our specific situation. We'll see!

I'll probably have some kind of draft PR that might not be representative of how we actually want to do this.