Skip to content
CCL

Roadmap

Roadmap

The feature path, oldest first.

This page only tracks user-facing wins: generators, language features, inputs, and output formats. Routine fixes and refactors stay in the commit log where they belong.

  1. Done v0.0.1

    Go + GDScript outputs

    CCL became useful as a real generator instead of only a language experiment.

    • Generate Go models for backend workflows.
    • Generate GDScript models for Godot projects.
    • Use CCL as one source of truth for two very different runtimes.

  2. Done v0.0.2

    Source-level generator controls

    Attributes let CCL files describe how generated code should look and behave.

    • Attach generation choices to the model definition itself.
    • Keep target-language output rules visible during code review.
    • Avoid scattering generator configuration across side files.

  3. Done v0.0.3

    Python, TS, JS, and C# targets

    The target list expanded from two languages into a broader multi-runtime story.

    • Python support started and reached working test coverage.
    • TypeScript, JavaScript, and C# generator work landed.
    • .cclinfo debug metadata made generated output easier to trace back to CCL sources.

  4. Done v0.0.4

    Imports + JSON output

    CCL source files became easier to split, reuse, and connect to JSON-heavy systems.

    • Import one CCL source file from another.
    • Generate JSON serialize/deserialize methods for supported targets.
    • Use scoped attributes and output file grouping for cleaner generated projects.

  5. Done v0.0.5

    First-class enums

    Enums moved into the language and generators as a proper model feature.

    • Define enums with default values and typedef-aware codegen.
    • Use nested enums without losing generated type names.
    • Control generated enum type and member prefixes when a target needs naming help.

  6. Next v0.0.5

    Rust + Zig outputs

    The next generator push targets systems languages without making users write them by hand first.

    • Rust output is planned for the current development line.
    • Zig output is planned for the current development line.
    • The goal is practical generated models first, then deeper target-specific polish.

  7. Planned

    C + C++ outputs

    Low-level targets stay on the roadmap for projects that need native integration.

    • C output is planned.
    • C++ output is planned.
    • The design should keep generated code inspectable instead of hiding behavior behind heavy dependencies.

  8. Planned

    Generics + maps

    Reusable typed shapes and map fields will make CCL models less repetitive.

    • Generics are planned for reusable model patterns.
    • Maps are planned for dictionary-like fields.
    • Generators will need consistent target-language mappings for both features.

  9. Planned

    OpenAPI + Telegram TL inputs

    CCL should be able to meet existing contracts instead of only starting from new CCL files.

    • OpenAPI input support is planned.
    • Telegram TL input support is planned.
    • These adapters would let CCL workflows start from formats teams already have.

  10. Planned

    Methods + inheritance

    Future CCL should describe more than fields when projects need richer generated APIs.

    • Method definitions are planned.
    • Proper inheritance support is planned.
    • The hard part is keeping generated code idiomatic across targets.