chore - Replace RFC 101 OrdinalKey bridge with RFC 098/099 trait-owned capability support

[dannymeijer]

Area

• Incan Language (syntax/semantics)
• Compiler (frontend/backend/codegen)
• Runtime / Core crates (stdlib/core/derive)

Summary

RFC 101 (std.collections.OrdinalMap) is implemented for v0.3, including the deterministic OrdinalKey surface and benchmarked lookup behavior. The v0.3 implementation deliberately carries a narrow Rust/compiler bridge for deterministic scalar key conformance because RFC 098 and RFC 099 are not in scope until v0.5.

This chore tracks paying down that bridge once the v0.5 trait-system work lands. It is blocked by:

• RFC 098: Native associated types for traits (RFC - Native associated types for traits #580)
• RFC 099: Generic trait-targeted methods and trait-owned capability families (RFC - Generic trait-targeted methods #581)

The goal is not to reopen RFC 101. The goal is to keep RFC 101's public behavior and performance while moving the remaining bridge into the proper Incan trait-system model.

Scope

• In scope:
  • Model OrdinalKey scalar conformance through the RFC 098/099 trait-owned capability-family machinery.
  • Preserve deterministic key support for strings, bytes, booleans, exact-width integers, decimal, UUID, civil date/time values, fixed-offset datetimes, and stable scalar value enums.
  • Remove or collapse the RFC 101-specific compiler bridge once the generic conformance mechanism can express the same facts.
  • Keep the std.collections.OrdinalMap public API and serialization contract stable.
  • Preserve the benchmark shape established by RFC 101, especially exact lookup and batch lookup behavior.
• Out of scope:
  • Changing OrdinalMap semantics or making unchecked lookup the default.
  • Adding float key support; float determinism remains a separate policy question.
  • Replacing OrdinalMap with a general physical database index abstraction.
• Risks:
  • The generic trait-system implementation must not regress the fast str/bytes lookup paths.
  • Capability-family coherence must remain deterministic: a concrete type can have only one visible OrdinalKey conformance.

Plan

1. Land the RFC 098 associated-type model needed by trait-owned capability metadata.
2. Land the RFC 099 generic trait-targeted method and trait-owned capability-family model.
3. Re-express the OrdinalKey deterministic scalar family through that model instead of RFC 101-specific compiler logic.
4. Remove the temporary bridge from the compiler/backend paths once equivalent source/metadata-driven conformance exists.
5. Re-run the RFC 101 benchmark suite at 1M keys/probes against Python dict, fastconstmap, and Incan OrdinalMap.
6. Update RFC 101's implementation notes if any bridge code remains intentionally generic infrastructure rather than feature-specific debt.

Done when

• RFC 098 and RFC 099 are implemented sufficiently for OrdinalKey scalar conformance to be expressed through the normal trait-system path.
• RFC 101-specific bridge logic is removed or replaced by generic trait capability-family infrastructure.
• OrdinalMap API, deterministic serialization, exact safe lookup, unchecked lookup, batch lookup, and supported key matrix continue to pass tests.
• Benchmarks remain credible against the RFC 101 baseline, with any regression explained and accepted explicitly.
• Documentation no longer describes the v0.3 bridge as active debt.

[dannymeijer]

Traceability note: this chore is blocked by RFC 098 (#580) and RFC 099 (#581). It is follow-up tech debt for implemented RFC 101 (#595), not remaining RFC 101 implementation scope.

[dannymeijer]

Implementation traceability update from the RFC 101 branch:

• The v0.3 bridge is now deliberately bounded: scalar OrdinalKey conformance remains a source-authored std.collections.OrdinalKey contract, with native helper behavior centralized under incan_stdlib::collections::__private and only Rust-coherence adapter stubs emitted by the backend.
• The current 1M-key benchmark shows the remaining performance debt is in generated ownership/borrow lowering, not in the public OrdinalMap contract: exact OrdinalMap[str] lookup is slower than fastconstmap.VerifiedConstMap, unchecked single-key lookup is faster than fastconstmap.ConstMap, and batch lookup is slower because generated Incan currently clones list/string values at batch call boundaries.
• The v0.5 cleanup should therefore cover both the RFC 098/099 trait-owned capability replacement and the related borrow-path cleanup needed to preserve RFC 101 performance without OrdinalMap-specific compiler branches.

This does not reopen RFC 101 semantics; it records the bridge/performance debt that remains after the v0.3 implementation.

[dannymeijer]

Implementation note from the RFC 101 PR review loop:

• The OrdinalMap[str] lookup accelerator has been moved out of backend-specific OrdinalMap emission and into stdlib-owned generated-code support metadata plus a stdlib macro that expands inside the generated std.collections module.
• The compiler side now consumes a generic registered method-fast-path descriptor; it does not carry an ordinal_map_methods.rs emitter slice or embed the lookup implementation body.
• The clone/borrow performance concern from the PR is not being tracked as accepted debt. The 1M benchmark was rerun after the registry change: Incan exact single-key lookup now beats fastconstmap.VerifiedConstMap in that local run, unchecked single-key/batch lookup beats fastconstmap.ConstMap, and exact batch lookup remains the main measured gap.
• This v0.5 chore should stay focused on replacing the remaining scalar OrdinalKey conformance bridge with RFC 098/099 trait-owned capability support while preserving the benchmark shape above.

[dannymeijer]

Refinement after running the repository layering guard:

• The compiler cannot depend on incan_stdlib as a normal dependency. The support descriptors therefore live in the lower shared semantic layer (incan_core::lang::generated_support) as pure metadata.
• The executable helper body remains centralized in incan_stdlib and is spliced into generated std.collections via the registered macro path.
• This keeps the backend generic, preserves the stdlib-owned Rust boundary for the hot lookup body, and respects the existing compiler/runtime layering rule.