Define traits for Unicode and ECMA 402 APIs

[filmil]

This issue a companion of: https://github.com/unicode-org/rust-discuss/issues/14.

How interested are we in general in having a common set of trait-specified API surfaces to program against? The idea is to allow multiple implementations, say omnicu (this work) and based on icu4c (like https://github.com/google/rust_icu). The theory is great, but practice is proving to be a bit more difficult than I thought.

Trying my hand at this I found that rust puts constraints on how the traits can look like, specifically since it is involved to return some useful forms of iterator.

Here's my attempt to work this out for https://github.com/zbraniecki/unic-locale/tree/master/unic-langid. For example, having a trait that returns an iterator trait (e.g. ExactSizeIterator) seems quite complicated because of the need to arrange the correct lifetimes of the iterator, the iterated-over-objects themselves, and the owner of the iterated-over objects. I got to this, but I'm not very happy about the outcome: https://github.com/unicode-org/rust-discuss/pull/19/files

FYI @zbraniecki

[nciric]

The core goal of OmnICU is to implement low level i18n algorithms, e.g. date formatting, collation, etc. Each client language will implement a wrapper, either around Rust low level library, or say Wasm export for JS/Dart.

We should see where those wrappers are located - are they part of OmnICU project, or are they separate repos/crates. A good example is your repo that wraps ICU4C - we can replace ICU4C parts over time with native Rust implementation without your users noticing.

@sffc

[sffc]

I think answering this question will be hard without more concrete examples of what OmnICU functional and ergonomic layers will actually look like. Let's revisit this question later in Q2 or in Q3.

[sffc]

I'm going to close this issue for now. I have it labeled with "backlog" to make it easy to find again and reopen when it is more appropriate.

[Manishearth]

• @hsivonen We have a spreadsheet that tracks ECMA-402 coverage. There are things missing. Does it correctly track the things Browsers would need? What will it realistically take to get to full ECMA-402 coverage? Can we going forward assume that if there is a 402 proposal, that it will be implemented in ICU4X, so that when the goalposts move, that they also help us keep up with the goalposts?
• @sffc We have most of the big things done. Date range is still outstanding. The rest is a lot of little things, including the wrapper layer, and generally driving us to full conformance. We haven't had an individual driving this, but if we turn our focus as a TC to getting there, I am somewhat confident that we could get there in some number of quarters. I plan to take the mantle on this in mid 2025 if no one else does.

[sffc]

I'm moving this to 2.2 because I want 2.2 to have an answer to the structure of these traits.

[nekevss]

Just to forward this discussion on this a bit. In Boa, there's a trait that's already been created to implement an Intl service.

The general module for Intl can be found here.

So far, each of the implemented built-ins have to implement a Service trait that is defined below (leaving some comments for a bit of context).

/// A service component that is part of the `Intl` API.
///
/// This needs to be implemented for every `Intl` service in order to use the functions
/// defined in `locale::utils`, such as locale resolution and selection.
trait Service {
    /// The data marker used by [`resolve_locale`][locale::resolve_locale] to decide
    /// which locales are supported by this service.
    type LangMarker: DataMarker;

    /// The attributes used to resolve the locale.
    const ATTRIBUTES: &'static DataMarkerAttributes = DataMarkerAttributes::empty();

    /// The set of options used in the [`Service::resolve`] method to resolve the provided
    /// locale.
    type LocaleOptions;

    /// Resolves the final value of `locale` from a set of `options`.
    ///
    /// The provided `options` will also be modified with the final values, in case there were
    /// changes in the resolution algorithm.
    ///
    /// # Note
    ///
    /// - A correct implementation must ensure `locale` and `options` are both written with the
    ///   new final values.
    /// - If the implementor service doesn't contain any `[[RelevantExtensionKeys]]`, this can be
    ///   skipped.
    fn resolve(
        _locale: &mut icu_locale::Locale,
        _options: &mut Self::LocaleOptions,
        _provider: &IntlProvider,
    ) {
    }
}

This trait is used to implement shared abstract operations: lookup_matching_locale_by_prefix, lookup_matching_locale_by_best_fit, resolve_locale, and filter_locale.