A Kotlin Multiplatform library of strongly-typed, shareable data types — money and currency, locales, coordinates and telemetry, GeoJSON geometry, RFC-compliant identifiers, and arbitrary-precision math. It exists because KMP projects kept redefining the same types incompatibly; these are the shared ones, with no platform-specific API leaking through.

Targets: Android, JVM, iOS, JS, Wasm and Linux.

Published to Maven Central as io.github.aughtone:types.

// build.gradle.kts
implementation("io.github.aughtone:types:4.0.0")

Or through a version catalog:

# gradle/libs.versions.toml
[versions]
aughtone-types = "4.0.0"

[libraries]
aughtone-types = { module = "io.github.aughtone:types", version.ref = "aughtone-types" }

// build.gradle.kts
implementation(libs.aughtone.types)

[!IMPORTANT] v4.0.0 Breaking Changes: A breaking release. Outcome.Error and Locale.toLanguageTag() are removed; Money equality is now numeric so 5.1 equals 5.10; Distance and Speed throw instead of clamping to zero; GeoBoundingBox leaves the geometry hierarchy; GeoFeature.properties becomes JsonObject; invalid GeoJSON is now rejected; and UnitOfMeasure.findFirst refuses ambiguous symbols rather than guessing. Several change behaviour without a compile error — see the changelog before upgrading.

v3.4.0 Outcome.Error renamed: The failure case of Outcome is now Outcome.Failure, and the factory is Outcome.failure(...). The old names shipped as deprecated aliases in 3.4.0 and are removed in 4.0.0. Outcome$Error no longer exists as a class, so upgrading from 3.3.0 needs a clean and rebuild rather than a code change.

v3.3.0 Locale Display Names: Eleven locale displayName values are corrected — renamed countries (Czechia, North Macedonia, Türkiye), incomplete or abbreviated country names, and dated language exonyms (Farsi → Persian, Azeri → Azerbaijani). No API changed, but snapshot tests and cached UI strings holding the old names will need updating. See the changelog for the full table.

v3.2.0 Behavioral Fixes: Still worth reading if you are coming from 3.1.x — that release corrected long-standing bugs whose output or validation changes for existing code. UrlEncoder.encode is now true RFC 3986 percent-encoding — use encodeFormData for the previous application/x-www-form-urlencoded behavior. Url/Uri/Urn/GeoUri string output is now well-formed, and Urn/GeoUri construction now rejects invalid input. Critical arbitrary-precision fixes also land in BigInteger/BigDecimal division and BankersValue. See the changelog for the full list.

v3.0.0 Breaking Change: All GeoJSON geometry types (e.g., Point, Polygon) have been renamed with a Geo prefix (e.g., GeoPoint, GeoPolygon). Money now uses BigDecimal for its internal value to support sub-minor units, and Telemetry has moved to the quantitative package.

• 📖 Developer Guide: Building, testing, publishing.
• ⚖️ Architecture Decision Records: Why the library is shaped this way, and what was rejected.
• 📜 Changelog: History of changes and release notes.
• 🗺️ How the docs work: The whole system — knowledge in docs/knowledge/, work in Issues.

• Locales: Locale.current or localeFor("fr-CH").
• Money: Money(12.50, Currency.Usd) or Money(BigDecimal("1.23456"), Currency.Eur).
• Telemetry: Telemetry(coords, speed = 2.5.mps, azimuth = 90.degrees).

• Distance: 100.meters or 5.kilometers.
• Units: UnitOfMeasure.Litre.symbol ("L"), MetricPrefix.Kilo.

• Identifiers: Url("https://pkg.dev"), Urn("urn:uuid:...").
• Geo: GeoUri(45.5, -122.6) (RFC 5870).

• Arbitrary Precision: BigInteger("999999999999999999999999") or BigDecimal("123.456").
• Rounding: BigDecimal("1.255").setScale(2, RoundingMode.HALF_EVEN) -> 1.26.

• Outcome: runOutcome { parse(input) } returns Outcome.Success or Outcome.Failure; when over the two, or use fold, map, recover, dataOrElse.
• Unlike kotlin.Result it is a sealed class, so Swift and JavaScript callers can read the failure as data. See ADR-0004.

• GeoJSON: GeoPoint(45.5, -122.6, 100.0).toGeoJson() (RFC 7946).

Locale.displayName from the bundled resource data is always English. To show a locale's name in the end user's own language:

localeFor("bn")?.localizedDisplayName() // "bengali" for a French user, "ベンガル語" for a Japanese user

Rather than bundling a full translation matrix (~90 × 90 names) into every app, this delegates to the CLDR data each platform already ships — java.util.Locale (JVM/Android), NSLocale (Apple), Intl.DisplayNames (JS/Wasm). Bundled resource files aren't viable everywhere: browsers can't read files synchronously, and klibs can't deliver resources into an iOS app bundle.

Tradeoffs to be aware of:

• Names come from the OS, so wording may differ slightly between platforms and OS versions (e.g. "Chinese (Simplified)" vs "Simplified Chinese").
• Linux targets have no system CLDR data — they always return the English fallback.
• Browsers need Intl.DisplayNames (widely available since ~2020); older environments fall back to English.
• The function never returns null — the worst case is the English displayName.

See ADR-0003 for the full rationale, and issue #20 for the deferred bundled-tables alternative.

To ensure mathematical precision and behavior consistency, this library employs rigorous Differential Parity Testing against standard baseline libraries:

• JVM Baseline: Parity verified against standard JDK types (java.math.BigInteger and java.math.BigDecimal).
• KMP Baseline: Parity verified against the official Multiplatform Ionspin BigNum library.

BigInteger and BigDecimal are benchmarked against the JDK types. Figures are relative to java.math, so 1.0x is parity and below 1.0x is faster than the JDK.

Small values are the exception, and deliberately so: the JDK keeps any BigDecimal under 19 digits in a long, so it answers toDouble on one by reading a field. There is no equivalent fast path here, and short-value operations run from several times to two orders of magnitude slower as a result. Two other costs are worth knowing: modPow is around 5x, lacking Montgomery reduction, and comparing two BigDecimal values of different scale is quick only when their magnitudes differ enough to settle it without aligning them — equal scales, the common case, beat the JDK.

Run them yourself with ./gradlew :benchmarks:benchmark. Ratios hold reasonably across machines; absolute throughput does not, so the benchmarks report both.