WORKING FOUNDATION · BROADER DESIGN OPEN
Text with explicit units.
String represents Unicode text; UTF-8 is the canonical internal representation. String already has strict UTF-8 conversion, byte-boundary helpers and UTF-8 ordinal ordering. Preview 8 has grapheme Char, String length and iteration, with explicit scalar access. Future questions include normalization, efficient traversal, text positions and a dedicated scalar type. This differs deliberately from .NET’s UTF-16 code unit and requires migration. Possible Utf8String and AsciiString types could provide encoding-specific guarantees alongside neutral String and Char. These types and broader encoding abstractions are deferred, not required next steps.
Current String implementation → · Text design and tradeoffs →
WORKING DISCOVERY · FUTURE CAPABILITIES
One descriptive model, different contexts.
TypeInfo, the sealed MemberInfo hierarchy and RuntimeContext provide basic discovery today. Future work may add dynamic assembly loading, offline metadata, invocation and emit. Compared with .NET’s reflection model, separating descriptions from execution could let tools reuse the model without loading code to run it. Resolution, lifetime and cross-context identity need explicit rules.
Dynamic loading belongs with RuntimeContext. Other runtime services might eventually live there too; an optional collector is an idea, not an implemented context API.
Current Introspection implementation → · Introspection design →
WORKING CAPABILITIES · OPEN EXTENSIONS
Read access without committing to storage.
Sequence, MutableSequence and List already distinguish read, replacement and growth. The development API now uses Filter/Map in place of Where/Select. Preview 8 retains its original names. Development now includes Any, All, Count, Take, Skip, Concat, FlatMap and seeded Fold. Seedless reduction, ordering and grouping remain open extensions. Future immutable or frozen providers and variance rules need explicit contracts. Compared with .NET read-only interfaces, the same caution applies: a read-only view may observe another alias’s mutations. Additional guarantees require more than a different interface name.
PARTIAL FOUNDATION · PROPOSED EXPANSION
Separate time from its presentation.
Date, Time, Instant, Duration and clocks provide the initial foundation. Proposed additions include time zones, calendars and immutable culture descriptions. .NET’s DateOnly, TimeOnly, TimeProvider and CultureInfo provide comparison points. Explicit concepts can clarify APIs, but bring more types, data dependencies and conversion rules. Culture-sensitive parsing and collation are not established by these proposals.
PROPOSED · CURRENT FILE HELPERS REMAIN
Make access a capability.
A FileSystem could resolve paths in a host, memory or packaged namespace. Readable, writable and seekable stream interfaces could express supported operations, rather than .NET Stream’s capability flags. This could improve testing and make unsupported operations harder to express, at the cost of more contracts and adapters. Current whole-file helpers remain bounded and synchronous; streams and their waiting behavior still need implementation and agreement.
EXPERIMENTAL MECHANISM · CONTRACTS FIRST
Completion, cancellation and failure.
The proposed Task model describes whether an asynchronous computation produced a value. A task starts Pending and ends Completed with a value, or Cancelled. Its State describes that lifecycle; its Outcome is absent while pending and contains the terminal outcome afterward. Expected operation failures remain ordinary Result values. Faults remain terminal runtime failures outside Task outcomes.
CancellationToken represents a request. The operation must observe it and choose to terminate before its task becomes Cancelled. The Map operator transforms a completed value; Then chains another task. Both propagate cancellation without invoking the skipped callback. They treat Result as an ordinary payload. Await is intended to propagate cancellation automatically, independently of Result propagation.
What works in development: the Raven-authored System.Tasks.Task<T> and Promise<T> PoC now exposes State and an optional terminal Outcome, with Complete/Cancel on the producer. Map and Then now compose those outcomes through queued callbacks, propagating cancellation without invoking skipped callbacks. The implementation supports ordinary values, unit and Result payloads, and named async functions. A pending await returns control and resumes when the explicit queue is drained. TaskQueue.Run establishes the active queue. A separate worker PoC exposes Thread.Start and ThreadPool.Queue: isolated workers exchange text and return Task<string>. The caller’s queue may block waiting for a worker; guest objects are not shared. These development APIs are not included in published Preview 8.
Next: add cancellation tokens, then adapt Raven’s await lowering to propagate cancellation. Explicit producer cancellation and Outcome inspection are implemented in development; awaiting a cancelled task is not supported yet. Rebuild callers and library artifacts together; Promise replaces TaskCompletionSource, and Complete replaces TrySetResult. State machines are provisional machinery; Raven may need a separate lowering, and runtime suspension remains a later goal. Compared with .NET’s exception-based Task behavior, this model exposes outcomes explicitly but requires different library and compiler contracts. Scheduling, cleanup, logical context and UI affinity still need work; the aim is to avoid routine ConfigureAwait-style boilerplate. Networking and HTTP remain proposals built on this foundation.
Task model proposal → · Implementation assessment → · Networking proposal →
ARCHITECTURAL EXPLORATION
Keep language and execution choices open.
The current backend is an interpreter. The architecture proposals explore native interoperation and language projections, while JIT or AOT execution remains future evaluation. .NET’s runtime, ABI and compiler layers are useful references. More execution paths could broaden use, but add ABI, verification and testing obligations; no replacement backend has been selected.
HELP TEST THE IDEAS
Bring a use case, not just a vote.
What are you trying to build? Which current contract gets in the way? A small example, an expected result or a counterexample helps us compare alternatives before expanding the API.