Hermeticum/slovo
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1185a1fa18
slovo/.llm/BETA_9_COLLECTION_ALIAS_UNIFICATION_AND_GENERIC_RESERVATION.md

2.2 KiB
Raw Blame History

1.0.0-beta.9 Collection Alias Unification And Generic Reservation

Status: release scope for 1.0.0-beta.9.

1.0.0-beta.9 is a Slovo stdlib/docs slice on top of the beta.8 concrete alias foundation. It applies transparent aliases to the repeated concrete collection and value-family facades without changing the public helper surface or executable semantics.

Source Surface

Current source-authored facades may declare module-local aliases such as:

(type VecBool (vec bool))
(type OptionString (option string))
(type ResultU64 (result u64 i32))

The aliases are used only inside their defining module. Exported helper names and helper meanings remain concrete, and importers observe normalized concrete types.

Applied Scope

  • lib/std/vec_i32.slo
  • lib/std/vec_i64.slo
  • lib/std/vec_f64.slo
  • lib/std/vec_bool.slo
  • lib/std/vec_string.slo
  • lib/std/option.slo
  • lib/std/result.slo

The vector facades use one local alias for the concrete vector family. The option and result facades use local aliases for the current concrete option and result families.

Contract

  • Current vectors remain concrete families: (vec i32), (vec i64), (vec f64), (vec bool), and (vec string).
  • Current options and results remain concrete families over the explicitly promoted payload shapes.
  • Aliases are transparent, module-local, and erased before typed-core lowering, backend layout, ABI decisions, runtime behavior, and cross-module signatures.
  • Public helper names, exports, constructors, runtime calls, and behavior are preserved.
  • Public API documentation must not turn these local aliases into imported public type names; the semantic contract is the normalized concrete target type.

Deferrals

This release does not add executable generics, generic aliases, parameterized aliases, maps, sets, traits, inference, monomorphization, iterators, new compiler-known runtime names, stable ABI/layout promises, or a stable standard-library API freeze.

The generic/map/set direction is reserved through diagnostics and design language only. Future work must define syntax, typed-core representation, lowering, conformance gates, compatibility policy, and stdlib migration rules before any executable generic collection surface is promoted.