DirectSharp roadmap
DirectSharp v1.0 has a frozen language design. The goal is a coherent language whose rules, examples and library contracts support readable everyday applications. The Customer showcase connects validation and lookup to concurrent dashboards, cancellable report workers and parallel processing.
The phases below describe dependencies rather than release dates.
1. Complete the learning and reference material
The specification defines syntax, binding, evaluation order, results, failure behavior and diagnostics. The detailed reference pairs those rules with valid examples, invalid cases and representative C# lowering. Particular attention goes to boundaries that are easy to miss: absence versus defaults, source exhaustion, partial results, cancellation, resource ownership and concurrent settlement.
The guide teaches ordinary classes, actions, interfaces, data, generics and class kind before advanced integration mechanisms. Application examples connect those ideas into customer validation, order processing, persistence, web APIs, imports and background work. Comparisons use equivalent tasks in C#, VB.NET, Python and other relevant languages, including comparable error handling.
The C#/VB.NET bridge, guided exercises, alphabetical lookup and chapter-based specification now supply those reading routes. The FAQ explains the design choices. This phase is complete when the learning paths and reference agree, examples have the necessary context and dependencies, and the established rules and their edge cases are easy to find. Consistent terminology and connected examples keep that material usable.
2. Define the library before writing it
The standard-library plan describes what the library must support and why. The API catalogue separates selected CLR declarations, typed source forms and export boundaries. The library reference records established contracts: Gate, consumable acquisition and adapters, sequence selection, text/Unicode, services and compiler support.
The catalogue records agreed declarations and their behavioral contracts. Where a final signature is still undecided, the plan describes the required semantics instead of publishing a guessed API. The boundary between public DirectSharp APIs and compiler-only runtime support must remain clear.
Each surface needs an implementation account: expected .NET mechanism, ownership, cancellation, exceptions, concurrency boundaries and cases to verify. Common forward-only sources include queues, stacks, completion-aware concurrent collections, channels, database readers, text lines and byte chunks. Ordinary .NET APIs remain directly usable; a DirectSharp wrapper is optional unless a specific language contract requires it.
The documentation and contract phases proceed together.
Completing the contract catalogues
The catalogue now records selected declarations and behavioral profiles. Remaining work concerns their final public binding and backend integration:
| Area | Recorded contract / remaining work |
|---|---|
| Consumable construction | Consumables factories and ILiveConsumable producer/terminal members are selected; private native registration is compiler integration work |
| Sequence and helper APIs | Strict/Try exports, TextExtensions/Numbers declarations and encoding profiles are selected; finish First/Last CLR typing and bare numeric-call binding |
| Service integration | Lookup signatures and identity-bearing exception constructors are selected; complete backend native adapters/capabilities without widening portable source semantics |
| Advanced feature/wrapper declarations | Source declaration/discovery/engine rules are documented; private metadata and engine-host/asset tooling remain implementation work |
| Reference coverage | Cross-check every published example, invalid case and C# pattern against its stated contract and dependencies |
The guide, examples and reference must agree throughout this work. Concrete implementation types, private helper ABI and performance choices can be settled during implementation while preserving the finished public contracts. Ordinary classes and direct .NET application code remain the main learning path.
Encoding examples show direct .NET URI/HTML/XML/JSON operations alongside the selected helper contexts and private C# patterns. Diagnostics and repairs and the read-chain rules explain why valid-looking code can have different absence, failure and ownership behavior.
3. Preserve the language contracts
Every implementation must preserve name and type binding, evaluation order, failure and lifetime behavior. Ordinary classes, actions and direct .NET calls are the foundation; advanced adapters build on those same rules.
4. Make everyday application work practical
Use the documented validation, persistence, HTTP, DI, logging and testing examples as integration cases. Verify real framework calls, cancellation propagation, disposal and deployment assumptions. Prioritize the ordinary .NET ecosystem over additional wrapper layers.
Beyond v1.0
Further language features are outside the frozen v1.0 scope. Optional framework conveniences and other backends can be explored when practical experience justifies them. .NET with a C# backend remains the v1.0 target; alternative-backend compatibility is not promised.
There are no date-based delivery commitments.