diff options
Diffstat (limited to 'vendor/icu_provider/src/constructors.rs')
| -rw-r--r-- | vendor/icu_provider/src/constructors.rs | 101 |
1 files changed, 101 insertions, 0 deletions
diff --git a/vendor/icu_provider/src/constructors.rs b/vendor/icu_provider/src/constructors.rs new file mode 100644 index 000000000..a9330c3f2 --- /dev/null +++ b/vendor/icu_provider/src/constructors.rs @@ -0,0 +1,101 @@ +// This file is part of ICU4X. For terms of use, please see the file +// called LICENSE at the top level of the ICU4X source tree +// (online at: https://github.com/unicode-org/icu4x/blob/main/LICENSE ). + +//! 📚 *This module documents ICU4X constructor signatures.* +//! +//! One of the key differences between ICU4X and its parent projects, ICU4C and ICU4J, is in how +//! it deals with locale data. +//! +//! In ICU4X, the data provider is an *explicit argument* whenever it is required by the library. +//! This enables ICU4X to achieve the following value propositions: +//! +//! 1. Configurable data sources (machine-readable data file, baked into code, JSON, etc). +//! 2. Dynamic data loading at runtime (load data on demand). +//! 3. Reduced overhead and code size (data is resolved locally at each call site). +//! 4. Explicit support for multiple ICU4X instances sharing data. +//! +//! In order to achieve these goals, there are 3 versions of all Rust ICU4X functions that +//! take a data provider argument: +//! +//! 1. `*_unstable` +//! 2. `*_with_any_provider` +//! 3. `*_with_buffer_provider` +//! +//! # Which constructor should I use? +//! +//! ## When to use `*_unstable` +//! +//! Use this constructor if your data provider implements the [`DataProvider`] trait for all +//! data structs in *current and future* ICU4X versions. Examples: +//! +//! 1. `BakedDataProvider` auto-regenerated on new ICU4X versions +//! 2. Anything with a _blanket_ [`DataProvider`] impl +//! +//! Since the exact set of bounds may change at any time, including in minor SemVer releases, +//! it is the client's responsibility to guarantee that the requirement is upheld. +//! +//! ## When to use `*_with_any_provider` +//! +//! Use this constructor if you need to use a provider that implements [`AnyProvider`] but not +//! [`DataProvider`]. Examples: +//! +//! 1. [`AnyPayloadProvider`] +//! 2. [`ForkByKeyProvider`] between two providers implementing [`AnyProvider`] +//! 3. Providers that cache or override certain keys but not others and therefore +//! can't implement [`DataProvider`] +//! +//! ## When to use `*_with_buffer_provider` +//! +//! Use this constructor if your data originates as byte buffers that need to be deserialized. +//! All such providers should implement [`BufferProvider`]. Examples: +//! +//! 1. [`BlobDataProvider`] +//! 2. [`FsDataProvider`] +//! 3. [`ForkByKeyProvider`] between any of the above +//! +//! Please note that you must enable the `"serde"` feature on each crate in which you use the +//! `*_with_buffer_provider` constructor. +//! +//! # Data Versioning Policy +//! +//! The `*_with_any_provider` and `*_with_buffer_provider` functions will succeed to compile and +//! run if given a data provider supporting all of the keys required for the object being +//! constructed, either the current or any previous version within the same SemVer major release. +//! For example, if a data file is built to support FooFormatter version 1.1, then FooFormatter +//! version 1.2 will be able to read the same data file. Likewise, backwards-compatible keys can +//! always be included by `icu_datagen` to support older library versions. +//! +//! The `*_unstable` functions are only guaranteed to work on data built for the exact same version +//! of ICU4X. The advantage of the `*_unstable` functions is that they result in the smallest code +//! size and allow for automatic data slicing when `BakedDataProvider` is used. However, the type +//! bounds of this function may change over time, breaking SemVer guarantees. These functions +//! should therefore only be used when you have full control over your data lifecycle at compile +//! time. +//! +//! # Data Providers Over FFI +//! +//! Over FFI, there is only one data provider type: [`ICU4XDataProvider`]. Internally, it is an +//! `enum` between `dyn `[`AnyProvider`] and `dyn `[`BufferProvider`]. +//! +//! To control for code size, there are two features, `any_provider` and `buffer_provider`, that +//! enable the corresponding items in the enum. +//! +//! In Rust ICU4X, a similar buffer/any enum approach was not taken because: +//! +//! 1. Feature-gating the enum branches gets complex across crates. +//! 2. Without feature gating, users need to carry Serde code even if they're not using it, +//! violating one of the core value propositions of ICU4X. +//! 3. We could reduce the number of constructors from 3 to 2 but not to 1, so the educational +//! benefit is limited. +//! +//! +//! [`DataProvider`]: crate::DataProvider +//! [`BufferProvider`]: crate::BufferProvider +//! [`AnyProvider`]: crate::AnyProvider +//! [`AnyPayloadProvider`]: ../../icu_provider_adapters/any_payload/struct.AnyPayloadProvider.html +//! [`ForkByKeyProvider`]: ../../icu_provider_adapters/fork/struct.ForkByKeyProvider.html +//! [`BlobDataProvider`]: ../../icu_provider_blob/struct.BlobDataProvider.html +//! [`StaticDataProvider`]: ../../icu_provider_blob/struct.StaticDataProvider.html +//! [`FsDataProvider`]: ../../icu_provider_blob/struct.FsDataProvider.html +//! [`ICU4XDataProvider`]: ../../icu_capi/provider/ffi/struct.ICU4XDataProvider.html |