Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Graduate Semantic Skeleta #5634

Open
43 tasks
sffc opened this issue Oct 1, 2024 · 0 comments
Open
43 tasks

Graduate Semantic Skeleta #5634

sffc opened this issue Oct 1, 2024 · 0 comments
Labels
C-datetime Component: datetime, calendars, time zones

Comments

@sffc
Copy link
Member

sffc commented Oct 1, 2024

  • 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
@sffc sffc added the C-datetime Component: datetime, calendars, time zones label Oct 1, 2024
@sffc sffc added this to the ICU4X 2.0 ⟨P1⟩ milestone Oct 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-datetime Component: datetime, calendars, time zones
Projects
None yet
Development

No branches or pull requests

1 participant