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
When discussing no_std (#77), we decided to shoot for no_std without alloc. I wanted to follow up on one aspect of that decision. It is very common in ICU code for the majority of operations to be performed without an allocation, but allocation may be necessary in edge cases. Therefore, when writing ICU4X code that works with no_std in 95% of cases, how should we handle cases when an allocation is required?
Panic
Ignore (e.g., don't push another element to a vector if it is full; safe, but undefined behavior)
Return error result
Conditionalize any such API on the std feature
Require the alloc trait
Option 1 is the easiest, but may be hostile to no_std users, since they can't know ahead of time whether or not their call will panic, and panicking is not recoverable. To a certain extent, we could rely on documentation for what edge cases trigger panics, but we risk the documentation getting stale.
Option 2 is also easy, but maybe we don't want to have undefined behavior.
Option 3 is harder, because it requires instrumenting our code up and down the stack to have fallible memory allocation, probably with clippy warnings to enforce it. However, this is ICU4C's style, so maybe it's not out-of -line for ICU4X.
Option 4 would be an unfortunate conclusion, because a large majority of ICU4X APIs will require allocation in at least some edge cases.
Okay. I'm clearly still not aligned with @Manishearth's line of thinking when it comes to no_std. 😕
Option 4 in effect means that we simply do not support no_std in most of ICU4X, and consider it a nice-to-have for some undetermined point in the future, with no clear roadmap to get there. That's not my vision, but maybe I should just give up on the advocacy for no_std.
Option 4 in effect means that we simply do not support no_std in most of ICU4X, and consider it a nice-to-have for some undetermined point in the future, with no clear roadmap to get there. That's not my vision, but maybe I should just give up on the advocacy for no_std.
That's not how I read it Shane. I read it as "let's get the right API working and then investigate how much of it we can tweak for no_std".
The way I read your position is that we need to aggressively enforce no_std today or otherwise it'll be a lot of work to do it later.
This worry is not my experience in Rust and a lot of projects addno_std feature as they mature. I think Manish is suggesting we do the same here.
When discussing no_std (#77), we decided to shoot for
no_std
withoutalloc
. I wanted to follow up on one aspect of that decision. It is very common in ICU code for the majority of operations to be performed without an allocation, but allocation may be necessary in edge cases. Therefore, when writing ICU4X code that works withno_std
in 95% of cases, how should we handle cases when an allocation is required?std
featurealloc
traitOption 1 is the easiest, but may be hostile to
no_std
users, since they can't know ahead of time whether or not their call will panic, and panicking is not recoverable. To a certain extent, we could rely on documentation for what edge cases trigger panics, but we risk the documentation getting stale.Option 2 is also easy, but maybe we don't want to have undefined behavior.
Option 3 is harder, because it requires instrumenting our code up and down the stack to have fallible memory allocation, probably with clippy warnings to enforce it. However, this is ICU4C's style, so maybe it's not out-of -line for ICU4X.
Option 4 would be an unfortunate conclusion, because a large majority of ICU4X APIs will require allocation in at least some edge cases.
Option 5 was shot down by multiple people in #77.
@Manishearth @hsivonen @zbraniecki
The text was updated successfully, but these errors were encountered: