Z++

An English programming language with a native compiler.

Write your own algorithms, define your own data, and build reusable programs with English constructs and mathematical expressions.

Project leader: MSXFury · Compiler: 0.2.0-alpha.1 · License: MIT

Official Discord · Language specification · Getting started · Roadmap · Verification

---

Project overview

Z++ is a programming-language project led by MSXFury. Its goal is to give programmers a clear English syntax for general-purpose computation while preserving precise, deterministic language semantics.

A Z++ program describes its own logic through variables, expressions, conditions, loops, functions, modules, and records. The compiler translates that logic into native machine code. Application algorithms belong in programs and libraries written by developers.

The current release implements a working general-purpose alpha core for Windows x86-64. It supports runtime input, reusable functions, recursive algorithms, collections, multiple source files, custom records, recoverable results, and filesystem operations. A mature package ecosystem, additional platforms, advanced tooling, and broader production validation remain future work.

Project identity

Property	Current value
Project	Z++
Project leader	MSXFury
Compiler/toolchain version	0.2.0-alpha.1
VS Code extension version	0.2.0
Native runtime interface	ABI 2
Development stage	General-purpose alpha core
Source extension	.z
Public compiler command	z++ / z++.exe
Compiler implementation	Rust, edition 2024
Native code generation	LLVM / Clang / LLD
Supported native target	Windows x86-64
License	MIT
Community	Official Z++ Discord

Version values are defined in Cargo.toml, runtime/Cargo.toml, and the extension manifest. The language status records the implementation boundary.

Contents

• Design principles
• Implemented features
• Getting started
• Language examples
• What you can build today
• Command-line interface
• Standard library
• Compiler architecture
• Detailed project structure
• Build and development
• Testing and completed milestones
• Current limitations
• Roadmap
• Recommended next engineering work
• Contributing
• Documentation
• Leadership and community
• License

Design principles

1. English programming constructs. Statements use defined English keywords such as Let, If, While, Function, and Return. Mathematical expressions can use familiar operators.
2. A precise language. English syntax follows a formal grammar. Arbitrary natural-language requests are not executable Z++ programs.
3. Programmer-defined behavior. Developers compose general constructs to implement their own algorithms. New application ideas should not require new compiler commands.
4. Native execution. The compiler emits LLVM IR and links native code. A native runtime supplies values and operating-system operations.
5. Deterministic compilation. The pipeline contains no AI service, whole-sentence lookup database, source eval, or generated Python/JavaScript execution.
6. Explicit semantics. Boolean conditions are strict, conversions are explicit, blocks have explicit endings, and lexical names are resolved before execution.
7. Separate engineering layers. Parsing, semantics, mathematics compatibility, lowering, backend generation, runtime behavior, and editor transport remain separate.
8. Evidence-based progress. A feature is implemented when real programs can use it through the compiler and runtime. Roadmap entries do not imply current support.

Implemented features

The following capabilities are implemented in the current alpha. Production maturity and limitations are described separately below.

Area	Available functionality	Semantics and boundaries
Values	Numbers, text, Booleans, nothing	Exact arbitrary-precision rational arithmetic, within resource limits
Variables	Let, Set, lexical scopes, shadowing	Unknown bindings and duplicate declarations in one scope are rejected
Expressions	Arithmetic, comparisons, grouping, unary signs	Mathematical symbols and defined English comparison phrases
Boolean logic	and, or, not	Short-circuit evaluation; conditions require Booleans
Conditions	If, Else, End if	Nested branches lower to native control flow
Loops	While, For each, Break, Continue	Lists, Unicode text, and lazy integer ranges
Functions	Parameters, calls, returns, forward references	Names and argument counts checked before execution
Recursion	Direct and mutual recursion	Runtime nesting limits apply; closures are unavailable
Lists	Construction, indexing, replacement, append	Zero-based indexing and value semantics
Modules	Relative imports, aliases, exports	Cycle rejection and deterministic once-only initialization
Custom records	Structures, constructors, field access and updates	Nominal identity, constructor arity checks, value semantics
Error values	Structured codes/messages and explicit results	Detection, propagation, transformation, and recovery through ordinary code
Console and files	Input, output, UTF-8 file reading/writing	Recoverable APIs alongside fatal-error variants
Native builds	Executable generation and direct execution	Matching zpp_runtime.dll required beside applications
Diagnostics	Lexer, parser, semantic, and runtime errors	Frontend source locations; runtime line-number diagnostics
VS Code	Highlighting, diagnostics, Run command, .z identity	Shared compiler diagnostics include unsaved open module buffers
Distribution	Windows installer, upgrader, uninstaller, checksums	Edited source preservation and retained upgrade backups
Compatibility	Original exact affine inequality subset	Frozen compatibility feature; general computation is the development focus

See the accepted language and standard-library contracts for exact behavior.

Getting started

Install a packaged toolchain

From an existing Z++ distribution directory, run:

.\install.ps1 -AddToPath -RegisterFiles -MakeDefault

The default installation directory is %LOCALAPPDATA%\Programs\Z++. -AddToPath exposes the compiler in new terminals. -RegisterFiles registers the source-file identity; -MakeDefault selects it as the per-user .z default while retaining the previous setting for uninstall.

To update an existing managed installation, run the new package's upgrader:

.\upgrade.ps1

The upgrader verifies checksums, preserves edited .z files, rejects other modified-file collisions, and retains previous files in a backup. See installation for ownership and uninstall behavior. These commands assume an available locally produced package; public release hosting and signing are not implied.

Run a program

Open a new PowerShell terminal in the project directory:

z++ --version
z++ main.z

The repository's main.z computes the sum of factorials from 1 through 5 and prints 153.

Run the larger example:

z++ examples\review\main.z

Enter 2 when asked for processing capacity. It computes routes, schedules work, generates primes, and writes zpp-review-report.txt in the current working directory.

Build a native application

z++ build examples\review\main.z -o review.exe
.\review.exe

Distribute both review.exe and its generated zpp_runtime.dll. The application does not need its .z source files, Rust, LLVM, or an installed compiler. Build outputs use fresh executable paths; the CLI refuses to overwrite an existing executable or incompatible runtime DLL.

Set up VS Code

Install the locally built extension package:

code --install-extension editor\vscode\z-plus-plus-0.2.0.vsix

Open a trusted workspace and select Z++: Run Current File from the Command Palette. If necessary, configure z-plus-plus.compilerPath and z-plus-plus.serverPath in User Settings. Reload VS Code after an upgrade.

The extension contributes the red Z language icon; the active file-icon theme can override it. See editor setup.

Language examples

Statement lines, including block openers and closers, end with a period. Indentation improves readability but does not define blocks. Keyword spelling and capitalization follow the grammar. Text uses double quotes, and # introduces a non-executable title line.

Variables, conditions, and iteration

Let scores be list of 72, 91, 64, 88.
Let total be 0.

For each score in scores.
    Set total to total + score.
    If score is at least 80.
        Print "Passed with distinction".
    Else.
        Print "Keep practicing".
    End if.
End for.

Print "Average: " + (call text with total / (call length with scores)).

Functions and recursion

Function factorial using quantity.
    If quantity <= 1.
        Return 1.
    End if.
    Return quantity * (call factorial with quantity - 1).
End function.

Print "Enter a number:".
Let quantity be call integer with (call input).
Print call factorial with quantity.

Calls use with; parameter declarations use using. Parentheses delimit nested calls inside larger expressions. Functions have independent lexical scopes and receive state through arguments.

Programmer-defined records

Structure Parcel with label, mass.

Let original be new Parcel with "Equipment", 7.
Let updated be original.
Set field mass of updated to 12.

Print field mass of original.
Print field mass of updated.

This prints 7 and 12. Updating the copied record does not modify the original. Constructor arity is checked during compilation; field existence is checked at runtime.

Reusable modules

Save this as utilities.z:

Export square.

Function square using value.
    Return value * value.
End function.

Use it from another .z file in the same directory:

Use "utilities.z" as utilities.
Print call square from utilities with 12.

Imports resolve relative to the importing source file. Symbols remain private unless exported. Types can also be exported and constructed through a module alias.

Recoverable errors

Let result be call numberResult with "invalid input".

If call succeeded with result.
    Print call unwrap with result.
Else.
    Let problem be call unwrap with result.
    Print call errorCode with problem.
    Print call errorMessage with problem.
End if.

unwrap extracts either variant's payload: the value on success or the error on failure. Propagation uses ordinary Return; recovery uses conditions. This model does not provide exception unwinding.

What you can build today

Program category	Available building blocks	Current boundary
Mathematical algorithms	Exact arithmetic, loops, recursion, comparisons	Resource limits; no general scientific-computing ecosystem
Text and file processing	UTF-8 I/O, split/join, lists, records	Byte buffers and rich filesystem APIs remain future work
Interactive console tools	Runtime input, validation, functions, output	No program command-line argument access
Scheduling and simulations	Custom records, bindings, loops, exact calculations	No parallel runtime or asynchronous scheduling API
Graph and collection algorithms	Nested lists, functions, results	Maps/sets and optimized collection APIs are planned
Multi-file libraries	Imports, exports, module-local names	No package registry or dependency version resolution

Substantial reference program

The review application and algorithm module contain 244 lines of Z++ across two files. They implement Dijkstra pathfinding and reconstruction, graph validation, stable insertion sorting, job scheduling, prime generation, recursive Euclidean GCD, input validation, error recovery, and report-file I/O.

Input/scenario	Expected computed result
Original graph	Distance 20, route [0, 2, 5, 4]
Modified graph copy	Distance 3; original still produces 20
Processing capacity 1	Elapsed 18, late jobs 4, weighted delay 71
Processing capacity 2	Elapsed 9, late jobs 1, weighted delay 10
Invalid numeric input	Recovered NumberError
GCD of 1071 and 462	21

These algorithms live in the .z files. Read the review guide for an independent evaluation workflow.

Command-line interface

Command	Purpose
z++ main.z	Compile and execute a project
z++ check main.z	Validate without executing
z++ check main.z --json	Machine-readable frontend diagnostics
z++ build main.z -o application.exe	Native executable and matching runtime DLL
z++ dump tokens main.z	Inspect lexical tokens
z++ dump ast main.z	Inspect the abstract syntax tree
z++ dump hir main.z	Inspect resolved semantic representation
z++ dump ir main.z	Inspect control-flow representation
z++ dump llvm main.z	Inspect generated LLVM IR
z++ --version	Display the toolchain version

Runtime file paths are relative to the working directory. Import paths are relative to the importing source file. See CLI documentation for exit codes and build behavior.

Standard library

Category	Functions
Console	input
Conversion	integer, number, text, numberResult
Collections and text	length, append, split, join, contains
Numerical operations	range, absolute, floor
Files	read, write, readResult, writeResult
Results	success, failure, succeeded, unwrap
Structured errors	error, errorCode, errorMessage

Print is a language statement. range produces lazy ascending integer iteration with an exclusive end. Text length/indexing/iteration use Unicode scalar values. Recoverable APIs return results; simpler variants can terminate execution on failure. See standard-library contracts.

Compiler architecture

.z source files and editor buffers
                  |
                  v
         Source management / lexer
                  |
                  v
       English parser + expression AST
                  |
                  v
       Module graph and symbol linking
                  |
                  v
       Semantic analysis / resolved HIR
                  |
                  v
       Control-flow IR with ownership
                  |
                  v
         LLVM IR / native linking
                  |
                  v
       Windows executable + runtime DLL

Stage	Responsibility	Implementation
Source management	Identity, byte spans, line/UTF-16 positions	source.rs
Lexing	Tokens, literals, operators, trivia	lexer.rs
Parsing	English blocks, calls, records, mathematical expressions	parser.rs, ast.rs
Project resolution	Imports, exports, cycles, initialization, editor overlays	project.rs
Semantics	Bindings, function resolution, arity, legal control flow	semantic.rs
Lowering	Blocks, branches, calls, iteration, ownership operations	ir.rs
Native backend	LLVM IR generation	codegen.rs
Runtime	Values, containers, records, results, iterators, I/O	runtime/lib.rs
CLI	Validation, linking, execution, diagnostics	cli/main.rs
Editor transport	LSP lifecycle, synchronization, project diagnostics	lsp/main.rs

Runtime handles use reference counting. Lowering accounts for scope exit, reassignment, loop control, and returns. Boolean short circuit becomes actual branch control flow. The runtime operates on values rather than interpreting source text or an AST.

Historical mathematical behavior is isolated in math.rs. See architecture and runtime ABI for implementation details and tradeoffs.

Detailed project structure

Z++/
|-- .cargo/
|   `-- config.toml                  Windows static CRT configuration
|-- .github/workflows/
|   `-- ci.yml                       Compiler/native acceptance workflow
|-- branding/
|   |-- red-z.svg                    Vector project identity
|   |-- red-z.png                    Raster project identity
|   `-- red-z.ico                    Windows source-file icon
|-- cli/
|   `-- main.rs                      Command-line behavior
|-- compiler/
|   |-- lib.rs                       Shared compiler entry points
|   |-- source.rs                    Files, spans, positions
|   |-- lexer.rs                     Tokenization
|   |-- parser.rs                    English grammar and expressions
|   |-- ast.rs                       Abstract syntax tree
|   |-- project.rs                   Module graph and symbol linking
|   |-- semantic.rs                  Scope and semantic resolution
|   |-- ir.rs                        Control flow and ownership lowering
|   |-- codegen.rs                   LLVM backend
|   |-- diagnostic.rs                Diagnostic presentation
|   `-- math.rs                      Mathematics compatibility layer
|-- runtime/
|   |-- Cargo.toml                   Native runtime crate
|   |-- lib.rs                       Native values and I/O
|   |-- abi.rs                       Shared ABI primitive identifiers
|   |-- declarations.ll              Current LLVM-facing ABI declarations
|   |-- windows.ll                   Historical ABI 1 implementation
|   `-- kernel32.def                 Historical ABI 1 import definitions
|-- lsp/
|   `-- main.rs                      Language Server Protocol transport
|-- editor/vscode/
|   |-- package.json                 Extension identity and contributions
|   |-- package-lock.json            Locked extension dependencies
|   |-- extension.js                 Language client and native Run task
|   |-- language-configuration.json  Editor language configuration
|   |-- syntaxes/zpp.tmLanguage.json Syntax highlighting
|   |-- icons/red-z.svg              Language icon
|   `-- test/index.js                Extension-host acceptance test
|-- examples/
|   |-- mathematics.z                Compatibility example
|   `-- review/
|       |-- main.z                   Multi-feature review application
|       `-- algorithms.z             Algorithms and record types
|-- installer/windows/
|   |-- install.ps1                  Fresh per-user installation
|   |-- upgrade.ps1                  Verified replacement and backups
|   `-- uninstall.ps1                Owned-file removal
|-- scripts/
|   |-- dev.ps1                      Development build/check helper
|   |-- acceptance.ps1               Native execution gates
|   |-- editor-test.ps1              Extension-host test launcher
|   |-- install-test.ps1             Installation and live-upgrade tests
|   |-- package.ps1                  Distribution and checksums
|   |-- review-package.ps1           Source review archive
|   |-- icons.ps1                    Icon generation
|   `-- extract-llvm.py              Development-only LLVM extraction
|-- spec/
|   |-- STATUS.md                    Capability status
|   |-- accepted/language.md         Accepted semantics
|   |-- grammar/zpp.ebnf             Language grammar
|   |-- diagnostics/README.md        Diagnostic reference
|   |-- semantics/mathematics.md     Compatibility semantics
|   `-- proposals/                  Historical design proposals
|-- tests/                          Compiler/CLI/LSP/native regressions
|-- benchmarks/frontend.rs          Compiler-stage benchmark harness
|-- docs/                           Architecture, guides, and evidence
|-- Cargo.toml                      Workspace and compiler manifest
|-- Cargo.lock                      Locked Rust dependencies
|-- main.z                          Small runnable entry example
|-- AGENTS.md                       Engineering rules
|-- LICENSE                         MIT license
`-- README.md                       Project and contributor entry point

Test organization

Test file	Focus
frontend.rs	Parsing, diagnostics, Unicode, recovery, oracle, fuzz smoke
cli.rs	CLI behavior, invalid files, JSON errors, no partial execution
phase1.rs	Runtime values, bindings, lexical scope
control_flow.rs	Conditions, short circuit, loops, break/continue
iteration.rs	Lists, Unicode text, lazy ranges
functions.rs	Calls, recursion, returns, generated identifiers
collections.rs	User-written sorting and value semantics
modules.rs	Visibility, cycles, initialization, source identity
records.rs	Custom types, construction, fields, copies
errors.rs	Propagation, recovery, file operations
native.rs	Native execution, reproducibility, output protection
review.rs	One compiled application, multiple inputs, source removal
runtime_failures.rs	Invalid operations and resource limits
lsp.rs	Diagnostic lifecycle through the server process

Runtime unit tests also live in runtime/lib.rs; editor-overlay tests live in lsp/main.rs.

Generated directories and artifacts

Path	Purpose	Repository treatment
target/	Rust build outputs and tests	Generated; ignored
dist/	Toolchain packages, native examples, review archives	Generated; ignored
.local/	Local development artifacts	Generated; ignored
editor/vscode/node_modules/	Extension dependencies	Generated; ignored
*.vsix	Packaged extensions	Generated; ignored
zpp-review-report.txt	Review-program output	Generated; ignored

The Python extraction helper is development tooling. Installed compilation and generated applications do not require Python.

Build and development

Prerequisites

Dependency	Verified configuration / purpose
Rust	1.94.1, MSVC x64 target; compiler, LSP, runtime, tests
Visual Studio C++ tools	MSVC x64 tools for linking the workspace
Windows SDK	Windows development libraries for source builds
LLVM	Clang and LLD 20.1.8 for native code generation
Node.js and npm	Extension dependency installation and VSIX packaging
VS Code	Compatible editor for interactive use and host tests

These are development dependencies. Users of a packaged toolchain do not need Rust, Node.js, Python, or the SDK.

Build and verify

Run in Developer PowerShell with MSVC and the Windows SDK configured:

cargo build --workspace --locked
cargo fmt --check
cargo clippy --all-targets -- -D warnings
cargo test

$env:ZPP_CLANG = 'C:\path\to\llvm\bin\clang.exe'
.\scripts\acceptance.ps1

cargo build --workspace --locked --release

Replace the example LLVM path with your installation. ZPP_RUNTIME_DIR optionally overrides runtime lookup. Packaged installations locate their own backend and runtime without these settings.

The workspace produces zpp-driver.exe, zpp-lsp.exe, zpp_runtime.dll, and its import library. Packaging exposes the internal driver as z++.exe.

Package the toolchain and extension

Choose a fresh package output directory:

.\scripts\package.ps1 -Output "$PWD\dist\z++-0.2.0-alpha.1"
.\scripts\install-test.ps1 -Package "$PWD\dist\z++-0.2.0-alpha.1"

Push-Location editor\vscode
npm ci --ignore-scripts
npm run package
Pop-Location

Use scripts/editor-test.ps1 for the real editor-host gate and scripts/review-package.ps1 for a source review archive. Packaging includes dependency notices and a SHA-256 manifest. See building, dependencies, and release procedure.

Testing and completed milestones

The latest recorded verification is dated 2026-09-11 for 0.2.0-alpha.1. It reports 51 passing tests: 36 backend-free tests and 15 native tests, plus separate installer and editor-host checks. These are recorded local results, not a claim that remote CI has run successfully.

Completed milestone	Recorded evidence
General runtime computation	Values, scopes, expressions, loops, and conditions execute natively
Reusable algorithms	Recursion, sorting, generated identifiers, independent expected results
Multi-file programs	Export visibility, cycle errors, once-only diamond initialization
Custom data and recovery	Record updates preserve originals; errors propagate and recover
Runtime-dependent results	Review executable built once, sources removed, different inputs supplied
Robustness checks	5,000-input fuzz smoke and 11,400-case compatibility oracle
Native safeguards	Invalid-operation, recursion-limit, rendering-limit, build-protection tests
Distribution	Release build, checksums, installation, upgrade, source-preserving uninstall
Live executable updates	Upgrade tested while a previous language server remains running
Editor integration	Actual diagnostics, edit recovery, icon contribution, Run task exit 0
Offline installed path	Installed compiler runs without development backend overrides

Native tests are intentionally ignored by ordinary cargo test. Run scripts/acceptance.ps1 to execute them. An ignored test is not a passing native test.

The verification report records evidence and qualifications. The CI workflow defines automated checks; its presence alone does not establish a successful remote run.

Current limitations

Area	Current limitation
Platforms	Windows x86-64 is the only implemented native target
Maturity	Alpha; no broad production certification or signed release
Types	Dynamic values; no static annotations, generics, interfaces, inheritance
Functions	No first-class function values, closures, or captures
Collections	No maps, sets, or byte buffers
Iteration	No public user-defined iterator protocol
Errors	Explicit results; no exception unwinding or complete runtime stack traces
Networking	No standard HTTP, sockets, servers, or database integration
Concurrency	No async/await, task scheduler, or parallel execution model
Packages	No registry, dependency resolver, or Z++ package lockfile
Interoperation	Internal runtime ABI exists; public FFI is unsupported
Editor	Completion, navigation, rename, formatting, debugging remain unimplemented
Performance	Boxed values, list copying, linear record-field lookup, full project rechecks
Builds	No persistent compilation cache or incremental native compilation

Resource limits include 1 MiB per source file, 256 modules per project, 256 nested runtime calls including entry, 128 container nesting levels, one million list elements, and 16 MiB limits for text/input/files/rendered output. Numbers have a configured precision limit. See the language and runtime documentation for the complete boundary.

Loops have no iteration-count cap. The runtime is not an execution sandbox. Invalid frontend programs are rejected before execution; runtime-dependent type, bounds, arithmetic, and resource errors are diagnosed when encountered.

Roadmap

Future entries describe proposed priorities, not release promises, accepted new syntax, or assigned dates. MSXFury leads project direction. Language changes must be reflected in the accepted specification before being advertised as supported.

Stage	Status	Scope	Completion evidence
1. Compiler foundation	Implemented	Sources, lexer, parser, AST, diagnostics, backend	Valid native programs and invalid-source rejection
2. Runtime computation	Implemented	Values, bindings, expressions, branches, While/For	Tests with changing runtime data
3. Reusable functions	Implemented	Arguments, returns, forward calls, recursion	User algorithms and arbitrary-name tests
4. Data and modularity	Implemented	Lists, imports/exports, records, result/error values	Multi-file execution and semantic regressions
5. Developer distribution	Implemented	CLI, LSP, VS Code Run, Windows packaging/upgrade	Installed-toolchain and editor-host validation
6. Reliability hardening	Proposed next	Runtime source identity, stack traces, wider fuzzing, resource audits	Located errors and reproducible regression cases
7. Collections and libraries	Planned	Maps, sets, bytes, broader text/filesystem APIs	Specified ownership, iteration, errors, native tests
8. Richer abstractions	Planned	First-class functions, closures, extensible iteration, type-system design	End-to-end composition across functions and containers
9. Tooling and build productivity	Planned	Navigation, completion, rename, formatter, caching	Tested editor workflows and measured build improvements
10. Package infrastructure	Planned	Manifests, resolution, lockfiles, distribution	Reproducible multi-package builds
11. Ecosystem integration	Long-term	Public FFI, networking, database/library integration	Real external integrations and resource/error contracts
12. Concurrency and portability	Long-term	Async execution, concurrency, additional targets	Platform-specific lifecycle and correctness tests
13. Production readiness	Long-term	Compatibility policy, security review, sustained fuzzing, signing, external workloads	Published release criteria satisfied by evidence

Later stages depend on earlier semantics and runtime contracts. Application frameworks should grow as libraries once the language provides the necessary primitives.

Recommended next engineering work

Priority	Work item	Why it matters	Suggested acceptance criterion
P1	Carry file identity through native diagnostics	Multi-file errors need an unambiguous location	Imported-function failure identifies its file and line
P1	Expand generated/adversarial tests	Larger programs combine ownership and control flow	Regressions cover nested returns, aliasing, modules, limits
P1	Measure runtime/compiler performance	Optimizations need representative evidence	Reproducible workloads report toolchain, time, and memory
P2	Specify and implement maps/sets	Associative data enables more applications	Access, updates, equality, iteration, errors tested
P2	Design first-class functions and closures	Callbacks need capture and lifetime rules	Captured values remain correct through returns and storage
P2	Improve editor navigation	Definitions/references aid multi-file development	LSP results use shared semantic resolution
P3	Define project/package metadata	Libraries need reproducible dependency boundaries	Deterministic local multi-package builds precede a registry
P3	Establish release-readiness criteria	Production claims need measurable thresholds	Documented compatibility, quality, distribution, validation

These are recommendations for upcoming work, not features implemented by this documentation update.

Contributing

Start with AGENTS.md, the accepted language, and the grammar. Discuss proposed language changes with project leadership before treating new syntax as accepted.

A contribution should describe the problem, intended semantics, affected layers, and verification. Language features need the complete source-to-execution path, valid and invalid programs, and programmer-defined names/data that demonstrate general behavior.

Required engineering checks:

cargo fmt --check
cargo clippy --all-targets -- -D warnings
cargo test
.\scripts\acceptance.ps1

Run editor, installation, or packaging checks when those components change. Preserve existing valid behavior unless a deliberate compatibility decision is documented. Keep application-specific algorithms in Z++ programs or libraries wherever existing primitives permit it.

Bug reports should include the version, a minimal .z reproduction, expected/actual behavior, command, and diagnostic output. Keep credentials and private data out of reproductions.

Documentation

Document	Purpose
Accepted language	Authoritative current syntax and semantics
Grammar	Formal productions
Language status	Capability and support boundaries
Standard library	Signatures and value/error contracts
Compiler architecture	Pipeline and engineering tradeoffs
Runtime and FFI	ABI, ownership, limits, interoperation boundary
CLI	Commands, arguments, outputs, exit codes
Build guide	Dependencies and source builds
Installation	Install, upgrade, registration, uninstall
Editor setup	VS Code and supported LSP behavior
Dependencies	Dependencies and licensing policy
Release procedure	Packaging and validation gates
Verification	Recorded results and limitations
Review guide	Independent implementation evaluation

Historical proposals and earlier reports provide design context. They do not override the accepted specification or current status document.

Leadership and community

Project leader: MSXFury

The official Z++ Discord is the community contact point for project discussion, feedback, program examples, and development ideas:

Join the Z++ Discord server

The project welcomes concrete bug reports, compiler/runtime contributions, documentation improvements, and independently written Z++ programs that exercise the language in new ways.

License

Z++ is distributed under the MIT License. Third-party components retain their own licenses. Packaged distributions include dependency notices; LLVM is distributed under its applicable license and exceptions.