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 over FFI we do things like ICU4XCollatorOptionsV1 (and functions accepting it are named like create_v1() so that the options structs can be evolved in the future.
At a high level, once rust-diplomat/diplomat#247 and rust-diplomat/diplomat#271 are fixed, we should keep the Rust struct names (as they map to C struct/function names), but we can diplomat-rename ICU4XCollatorOptionsV1 to icu4x::CollatorOptions, and create_v1() to create().
When in the future we add more fields, we create a ICU4XCollatorOptionsV2 and create_v2, hook it up with defaults infrastructure so that old code constructing the old options bags will seamlessly work, and then move the diplomat-renames over to these new APIs whilst diplomat-disabling the old ones.
This maintains ABI stability (the old methods are available and unchanged), and is seamless from the perspective of higher-level API users.
I would like this to be solved for 2.0.
The text was updated successfully, but these errors were encountered:
Related: #3790
Part of #2856
Currently over FFI we do things like
ICU4XCollatorOptionsV1
(and functions accepting it are named likecreate_v1()
so that the options structs can be evolved in the future.At a high level, once rust-diplomat/diplomat#247 and rust-diplomat/diplomat#271 are fixed, we should keep the Rust struct names (as they map to C struct/function names), but we can diplomat-rename
ICU4XCollatorOptionsV1
toicu4x::CollatorOptions
, andcreate_v1()
tocreate()
.When in the future we add more fields, we create a
ICU4XCollatorOptionsV2
andcreate_v2
, hook it up with defaults infrastructure so that old code constructing the old options bags will seamlessly work, and then move the diplomat-renames over to these new APIs whilst diplomat-disabling the old ones.This maintains ABI stability (the old methods are available and unchanged), and is seamless from the perspective of higher-level API users.
I would like this to be solved for 2.0.
The text was updated successfully, but these errors were encountered: