Qt Bridges is a new door

into the ecosystem.

But this session is about different ones

Where Qt Bridges stands

• The first phase: Rust and C# (TP)
• QML owns the UI, your language owns the logic

Where Qt Bridges could be

The questions for this room

• Which other languages deserve a place in the Qt ecosystem?
• A a binding, a bridge or something else?
• How can  Qt  you help?

What is in the Qt 5 meta-repository?

Lines of code with cloc, 6.8M in total, 3rdparty excluded. Highlighted: languages from the watch list or the Qt Bridges candidates.

Skipped: HTML, XML, Markdown, CSS, Text, JSON, SVG, YAML, TOML, XSLT, XSD, diff, INI, CSV, Qt Linguist, XML (Qt/GTK), Qt Project, Mustache, ProGuard, Protocol Buffers, DTD, PO File, JSON5, PlantUML, IDL, Properties, Windows Resource File, Windows Module Definition, ANTLR Grammar, lex, reStructuredText

Signals from outside Qt

Lesson: adoption wins when the new language is invisible at the boundary, and a framework that talks to one language is great.

Signals from inside Qt

The quietest way a language enters an ecosystem is through the build.

What ruff and uv actually did

    $ pip install flake8 isort pyupgrade ...
    $ flake8 .          # seconds

    $ pip install ruff
    $ ruff check .      # milliseconds
    

Qt ships a whole family of exactly this kind of tool.

Which Qt tools would be the first candidates?

Two proofs of concept, and a safe way to try

    for f in $(find . -name '*.qrc'); do
      rcc    "$f" -o /tmp/cpp.cpp
      rcc-rs "$f" -o /tmp/rs.cpp
      cmp /tmp/cpp.cpp /tmp/rs.cpp || echo "DIFF $f"
    done
    

Why this is different from Qt Bridges

A taxonomy of ways in

Door 1 and 2: binding vs bridge

Both need someone paid or devoted to keep them alive.

Door 3: Interop, let the language come to us

    // Zig: headers become declarations
    const c = @cImport({
        @cInclude("qt_shim.h");
    });

    pub fn main() void {
        const app = c.qapp_new();
        defer c.qapp_free(app);
        _ = c.qapp_exec(app);
    }
    

The missing piece: a C ABI for the meta-object system

• Zig, Go, Odin, Nim, Crystal, Gleam (via NIFs), Swift, C#, Java… all can call C
• None of them can call C++ templates, overloads and virtuals in a stable way
• Every project today writes its own shim: miqt for Go, cxx-qt for Rust, bespoke ones elsewhere

A tiny, officially stable C surface for registering types, properties, signals and slots with the QML engine would be a force multiplier.

A sketch of the C surface

    /* qt_shim.h: hypothetical, illustrative only */
    typedef struct QtApp  QtApp;
    typedef struct QtType QtType;

    QtApp  *qtapp_new(int argc, char **argv);
    int     qtapp_exec(QtApp *);

    QtType *qttype_begin(const char *qml_name);
    void    qttype_property(QtType *, const char *name,
                            int meta_type,
                            QtGetter, QtSetter,
                            const char *notify);
    void    qttype_slot(QtType *, const char *name,
                        QtSlot fn);
    int     qttype_register(QtApp *, QtType *,
                            const char *uri,
                            int major, int minor);
    

Door 4 and 5: toolchain and protocol

Protocol is underrated: great for Elixir, Gleam and Go back ends, where the runtime is the point.

C++26 reflection: what is real today

• Static reflection (P2996 + P3394) is part of C++26: ^^T, std::meta, annotations [[= ...]]
• GCC 16 has a partial implementation with -std=c++26 -freflection
• Mainline Clang and MSVC: no production-ready support (Bloomberg has Clang fork 2996)
• Reflection help generate new declarations or types in supported contexts (Cannot add data-members, or code injection)

Qt supports all three compilers, so moc cannot go away soon. The question is the direction.

First steps inside Qt

    // from the QRangeModel post
    static consteval auto count()
    {
      constexpr auto ctx =
        std::meta::access_context::current();
      return nonstatic_data_members_of(
                 ^^T, ctx).size();
    }
    

And a community proof of concept: reflect-moc

    class Counter : public QObject {
      RQT_OBJECT
      RQT_PROPERTY(int value READ value
                   WRITE setValue
                   NOTIFY valueChanged)
    public:
      int value() const { return value_; }
      [[= rqt::slot]] void setValue(int v) {
        if (v == value_) return;
        value_ = v;
        emit valueChanged(v);
      }
      [[= rqt::names("value")]]
      rqt::signal<void(int)> valueChanged;
    private:
      int value_ = 0;
    };
    

What a moc-less future means for other languages

• Bindings targets the same QMetaObject table, so how it is made matters, not only C++
• Good: Compiler-generated metadata could be easier for language bindings to consume.
• Good: A C-style registration API could simplify cross-language integration.
• Risk: Two ways to build a meta-object; bridges and generators must handle both
• Risk: QML_ELEMENT and qmltyperegistrar sit on top of moc output today

Reflection is C++ arriving where Rust, Swift and Zig already are: describe the type, let the compiler do the rest.

Who is on the watch list?

…and a long tail: Go, Nim, Crystal, D, Dart, Roc, Hylo, cppfront

qt-swift: Qt's C++ API, imported, not mirrored

    import QtWidgets

    @main
    struct HelloWidgets: QtApplication {
        init() {
            let title: QString = "Hello, Qt!"
            let widget = QWidget()
            widget.setWindowTitle(title)
            widget.resize(400, 300)
            widget.show()
        }
    }
    

qt-swift: what it tells us

The missing half is a bridge: Swift types exposed to QML. Annotations in the headers and the reflection work both help here. It is the natural next phase.

Zig: why people care

    const std = @import("std");

    pub fn main() void {
        std.debug.print("Hello!\n", .{});
    }
    

Zig and Qt: the honest view

Verdict: a community project if we provide the C surface.

Gleam: friendly, and a protocol fit

    import gleam/io

    pub fn main() {
      io.println("Hello, Qt!")
    }
    

Verdict: protocol first (Gleam back end, QML front end). A bridge is the wrong shape here.

Carbon: the C++ successor attempt

• Started at Google, experimental, explicitly not ready for use
• Goal: bidirectional C++ interop good enough to migrate incrementally
• The roadmap has been about a working toolchain with C++ interop; there is no 1.0

Qt is exactly the kind of codebase Carbon's story is written for: huge, templated, macro-heavy, moc-processed C++.

Carbon: what the code looks like

    package Sample api;

    class Counter {
      var value: i32;

      fn Add[addr self: Self*](n: i32) {
        self->value += n;
      }
    }

    fn Main() -> i32 {
      var c: Counter = {.value = 0};
      c.Add(42);
      return c.value;
    }
    

Verdict: watch, do not bet, and the same for cppfront. Keep Qt headers clean, and tell the Carbon team how Q_OBJECT breaks things.

Mojo: the news is recent

• 1.0 released in August 2026, and the compiler was open sourced under Apache 2.0
• Modular is now part of Qualcomm, a name that Qt knows well
• Python-like syntax, but no longer promising to be a Python superset
• Designed for GPU and accelerator programming first

Mojo can import Python modules, so PySide is reachable in principle today.

Mojo: what the code looks like

    struct Point:
        var x: Float64
        var y: Float64

        def __init__(out self, x: Float64, y: Float64):
            self.x = x
            self.y = y

        def scale(mut self, k: Float64):
            self.x *= k
            self.y *= k

    def main():
        var p = Point(1.5, 2.0)
        p.scale(2.0)
        print(p.x, p.y)
    

    from python import Python

    def main():
        var qt = Python.import_module(
            "PySide6.QtCore")
        print(qt.__version__)
    

Under Mojo: MLIR, and what Qt could learn

Qt’s QML and shader pipelines offer precedents for staged compilation, but cross-language bindings still need explicit integration.

The same function, three IRs

    func.func @add(%a: i32,
                   %b: i32) -> i32 {
      %0 = arith.addi %a, %b : i32
      func.return %0 : i32
    }
    

    define i32 @add(i32 %a, i32 %b) {
    entry:
      %0 = add i32 %a, %b
      ret i32 %0
    }
    

    function %add(i32, i32) -> i32 {
    block0(v0: i32, v1: i32):
        v2 = iadd v0, v1
        return v2
    }
    

For one add they look alike: the difference shows up with tensors, GPUs and compile time, not with integers.

V (Vlang): simple, and not a priority

    #flag -lm
    #include <math.h>

    fn C.sqrt(x f64) f64

    fn main() {
        name := 'Qt'
        println('Hello, ${name}!')
        println(C.sqrt(2.0))
    }
    

Verdict: nothing to do except publish the C surface and let anyone try.

Odin: a C alternative, a good community project

    package main

    foreign import qtshim "system:qtshim"

    @(default_calling_convention = "c")
    foreign qtshim {
        qtapp_new  :: proc(argc: i32,
                           argv: [^]cstring) -> rawptr ---
        qtapp_exec :: proc(app: rawptr) -> i32 ---
    }

    main :: proc() {
        app := qtapp_new(0, nil)
        _ = qtapp_exec(app)
    }
    

Verdict: friendly tier. With the C surface, an Odin vendor:qt is a weekend of someone else's work.

Goose: safe, compiles to C, not actionable

    // calling C
    extern fn hypot(x: f64, y: f64) -> f64;

    // a generic function
    fn twice(x) { x + x }

    // a growable array of structs
    var items: Item[>..] = [];
    

Verdict: watch. Emitting C means the C surface is the whole interop story.

The long tail

My (subjective) scorecard

green good fit - orange workable - red gap

Reading the table

• Some languages already have a metadata story: that is why the bridges exist
• Zig is the surprise: comptime gives it bridge-quality ergonomics, with C-only interop as the single hard blocker
• Gleam and Carbon do not need a bridge: one needs a protocol, the other needs time
• V and Odin score on interop and nothing else: great consumers of a C surface, poor candidates for a bridge

Six low-cost moves

1. A stable C surface for type registration with the QML engine
2. Machine-readable API promoted to a contract: metatypes.json and qmltypes as inputs for generators
3. Annotations on public headers, following the Swift initiative
4. A conformance suite: a small QML app any bridge can implement and run in CI
5. A protocol-first recipe: Qt Quick front end plus any back end, documented and tested
6. Stay reflection-ready: keep the meta-object description clean enough that moc or a compiler can produce it

A commitment model

The top tier is expensive on purpose. The lower tiers let communities do the expensive part.

Proposed entry criteria

• A named, active maintainer group that is not "the Qt Company"
• Real production users of the language on desktop or embedded
• Passes the conformance suite on Linux, Windows and macOS
• Uses only the stable, documented surface (no private headers)
• A release cadence that follows Qt's, or a clear compatibility range

Some died from the maintenance tail: a new language needs an owner outside Qt before it needs a place inside it.

Questions for the room

1. Which language would you want to write Qt apps in next year?
2. Is a C ABI for the meta-object system worth maintaining?
3. Do the tiers and entry criteria make sense, or are they too heavy?
4. Which Qt tool would you port to Rust first, and what is the bootstrap policy?
5. How should Qt plan for moc and C++26 reflection while Clang and MSVC lag?
6. Who here would volunteer to try Zig, Odin or Go against a C shim?

The future of Qt is polyglot

Qt does not have to choose the next language.

It has to be easy to arrive at.