RFC: Opting for comptime-based inheritance validation for polymorphic parameters

[rcalixte]

While support for dot-call syntax is being explored, the resulting parameter type ambiguity remains. Take the abbreviated helloworld example after the dot-call syntax is applied:

pub fn main() void {
    const argc = std.os.argv.len;
    const argv = std.os.argv.ptr;
    const qapp = QApplication.New(argc, argv);
    defer qapp.Delete();

    const text = "Hello world!";
    const widget = QWidget.New2();
    if (widget.ptr == null) @panic("Failed to create widget");
    defer widget.Delete();

    const button = QPushButton.New5(text, widget.ptr);
    button.SetFixedWidth(320);
    button.OnClicked(button_callback);

    widget.Show();

    _ = QApplication.Exec();
}

In this structure, the function definition for QPushButton.New5 becomes:

    pub fn New5(text: []const u8, parent: ?*anyopaque) QPushButton {
        const text_str = qtc.libqt_string{
            .len = text.len,
            .data = text.ptr,
        };

        return .{ .ptr = qtc.QPushButton_new5(text_str, @ptrCast(parent)) };
    }

This structure requires call site syntax for each polymorphic parameter (.ptr) and still affords no safety if an improper parameter type is passed, leading to the potential for runtime crashes or undefined behavior.

The question becomes, "what if this syntax could be safer and offer a simpler interface?"

If adopted, the proposal would change the call site syntax to:

    const button = QPushButton.New5(text, widget);

The function definition would become:

// anytype instead of ?*anyopaque
pub fn New5(text: []const u8, parent: anytype) QPushButton {
    // this check would be repeated per polymorphic parameter type per function
    comptime validateQWidget(@TypeOf(parent));
    const text_str = qtc.libqt_string{
        .len = text.len,
        .data = text.ptr,
    };

    return .{ .ptr = qtc.QPushButton_new5(text_str, @ptrCast(parent.ptr)) };
}

The comptime validation would be backed by generated functions and correlating StaticStringMaps:

pub fn validateQWidget(comptime T: type) void {
    if (!QWidgetMap.has(@typeName(T))) @compileError("Invalid QWidget-derived type: " ++ @typeName(T));
}

// this is actually hundreds of types but for the sake of an example
const QWidgetMap: std.StaticStringMap(void) = .initComptime(.{.{ "libqwidget.QWidget", {} }});

Zig zen favors the comptime approach:

• Compile errors are better than runtime crashes.

[rcalixte]

Due to how the type system is currently projected, the comptime checking approach is brittle, leading to false negatives:

error: Type 'QStringListModel' is not a QAbstractItemModel-derived object

[whatisaphone]

Isn't there a proposal to remove @typeName? My first idea would be comptime reflection, something like this:

pub const QPushButton = opaque {
    pub const is_qwidget = true;
    // rest of methods, etc
};

pub fn New5(text: []const u8, parent: anytype) QPushButton {
    _ = @TypeOf(parent).Pointer.child.is_qwidget; // verify the magic field exists
    // ...
}

Or you could even generalize it something like pub const qbaseclass = QAbstractButton, and have a function to traverse the class hierarchy. That would allow casting safety for all classes, not just QWidget.

[rcalixte]

Or you could even generalize it something like pub const qbaseclass = QAbstractButton, and have a function to traverse the class hierarchy. That would allow casting safety for all classes, not just QWidget.

The QWidget example was just a hand-binding proof-of-concept. If you look at the example, this approach will not scale for certain classes, such as those that are derived from container types. That is, two different and unrelated classes both inherit from QList<int> will result in false positives. The library also contains classes inherited from blocked types, which leads to a broken inheritance chain.

I was hoping to be able to get a test in place so that measurements like impact to compilation time could be assessed using the examples and the demo as a base but the approach never got that far. I'm also loathe to make what could end up being two major breaking changes, strictly to the API, no matter how trivial porting might be.

pub const QPushButton = opaque {
    pub const is_qwidget = true;
    // rest of methods, etc
};

    _ = @TypeOf(parent).Pointer.child.is_qwidget; // verify the magic field exists

This leads to vague compilation error messages but the basic boolean structure is an idea. It would be rather extensive i.e. QPushButton inherits from QAbstractButton which inherits from QWidget which inherits from QObject and QPaintDevice. Either way, expressing this in native Zig is a combinatorial expansion regardless of the actual implementation.

[rcalixte]

I think I've reached a conclusion I'm satisfied with. Thanks for the extra nudge @whatisaphone. 🙏🏼

[rcalixte]

One other impediment is that this breaks the ability to pass null parameter types (where valid) as direct parameters. This is survivable but with more verbose parameter syntax.