Open sffc opened 1 year ago
crate::provider::Baked
is an implementation detail in the unstable provider modules. Users can use compiled data by depending on the data crates and creating their own baked providers:
struct MyBakedProvider;
icu_datetime_data::impl_datetime_chinese_datelengths_v1!(MyBakedProvider);
icu_datetime_data::impl_datetime_chinese_datesymbols_v1!(MyBakedProvider);
icu_list_data::impl_and_list_v1!(MyBakedProvider);
Discuss with:
Discussion: revisit this in the context of #3947, when we remove AnyProvider. Leaving some breadcrumbs for my mental model of this and #1893:
impl_forking_keyed_provider!([key1, key2, key3], Provider1, Provider2)
that generates a impl<M: KeyedDataMarker> DataProvider<M>
where the list of keys go to Provider1
and any key not in the list goes to Provider2
. Note that DCE should work fine through this layer because the match arm is statically known based on M::KEY
.provider::Baked
impls can have a function that internally contains this match statement for all of the keys it supports.Another use case here is if you want your language packs to contain only non-singleton keys and get the singleton keys from compiled data with the non-singleton keys from dynamically loaded data.
A few approaches here:
with_any_provider
constructors and a registry macro that forks between the singleton compiled data and the blob dynamic data_unstable
constructors (but then we don't handle older blob data)_unstable_with_backwards_compatibility
_with_buffer_provider
and export the singleton keys as blobs from the data crates_with_provider
constructors that take an enum between BufferProvider and AnyProvider (or equivalent) and fork between the singleton static data and the blob data (and use this opportunity to reduce the number of constructors -- rather than deleting _with_any_provider
we merge it in with the buffer provider constructor, which slightly increases the buffer provider constructor code size but only by the size of a ZeroFrom)Probably doesn't block 2.0 so removing it from that milestone, but it is still important.
Users should be able to chain provider::Baked providers to make a multi-crate AnyProvider.
@Manishearth suggested
aked.add(otherprovider::Baked)
making a fork provider.