Graduate Semantic Skeleta

[sffc]

• [ ] The crate should fully conform with the ICU4X Style Guide:
  • [ ] The crate should have a complete library header as shown in boilerplate.md with Clippy passing
  • [ ] The names of exported types should conform to the recommendations in the Style Guide
  • [ ] All Error types should be Copy
  • [ ] All constructors should take options structs by value
  • [ ] All constructors should take arguments in the following order: Provider, Locale, Options
  • [ ] All constructors should have the standard set of overloads for provider types
  • [ ] Runtime dependencies should be minimal and able to be disabled with Cargo features if possible
  • [ ] Any TODO, FIXME, todo!, unimplemented!, or other placeholders should either be resolved or link to an issue number. (It is okay to ship a small amount of code with tech debt comments, but anything having to do with code correctness should be resolved)
• [ ] The crate should have a conventional Cargo.toml file:
  • [ ] Cargo.toml should use license, not license-file
  • [ ] The description should be useful
  • [ ] Correct repo link, authors, categories, include
  • [ ] Correct docs.rs and cargo-all-features metadata settings
  • [ ] A rust-version field with the MSRV of this crate in accordance with the current ICU4X policies on MSRV.
  • [ ] The crate should have an std feature if (and only if) it contains code that depends on std, such as file I/O or implementing the Error trait
  • [ ] Audit all features so that any foo/bar in a feature is foo?/bar when foo is an optional dep; if you intend to enable foo, add two entries
  • [ ] Use dep: for enabling dependencies
• [ ] The crate should be fully documented
  • [ ] Every exported function should have docs coverage
  • [ ] There should be a crate-level example that illustrates a common use case for the component with the heading # Examples
  • [ ] All options and conditional code paths should have a corresponding docs test with the heading # Examples
  • [ ] All functions that are conditional on a Cargo feature should say so (last line before # Examples): ✨ *Enabled with the `alloc` Cargo feature.*
  • [ ] Compiled data constructors should say "with compiled data" in the first sentence and should have a Cargo feature alert following the above syntax.
• [ ] The APIs should follow ICU4X style
  • [ ] All options bags should be Copy (and contain references if they need to). Exceptions can be made by discussion.
• [ ] The data structs should fully follow ZeroVec style
  • [ ] Deserialization should not have a "zero-copy violation" in the make-testdata test
  • [ ] Constructors should avoid allocating memory in the common case
  • [ ] Opaque blobs of data should be avoided if possible (instead use VarZeroVec, ZeroMap, etc.)
  • [ ] Data structs should not be panicky to load/deserialize and conform to data_safety.md
  • [ ] If any data structs use a large or unbounded number of data marker attributes, they are implemented in a way that reduces stack space, file size, and construction time, such as by having only a single variable-length field
• [ ] The component should be fully integrated with ICU4X tooling
  • [ ] There should be an overview Criterion benchmark
  • [ ] There should be individual Criterion benchmarks for interesting or performance critical code paths
  • [ ] There should be at least one example plumbed with the icu_benchmark_macros
  • [ ] The component should be fully covered by FFI with no unjustified suppressions nor entries in missing_apis.txt
• [ ] The component should encourage i18n best practices
  • [ ] The component should produce correct results in all locales as generated by icu4x-datagen
  • [ ] Where applicable, the component should be consistent with ECMA-402 and UTS#35
  • [ ] Any gaps in i18n quality should be fixed, or, if that is not possible, they should have tracking issues and a concrete, resourced path forward. The intent is to not ship components with known i18n correctness problems and no plan to fix them in an upcoming release
  • [ ] The API design should receive sign-off from a non-ICU4X i18n expert such as Markus Scherer
• [ ] Add the new features to the changelog in the "Unreleased" section