Attach Methods to a union created with @Type

Help
, ,
1

Given the following union:

pub const Value = union(ValueType) {
    Class: *Vm.Class,
    Function: *Vm.Function,
    Instance: *Vm.Instance,
    List: *Vm.List,
    Matrix: *Vm.Matrix,
    NativeFunction: *Vm.NativeFunction,
    String: *Vm.String,
    Vector: *Vm.Vector,

    /// Nil is falsey, 'false' too, otherwise it's truthy.
    pub fn isFalsey(self: Value) bool {
        return switch (self) {
            .Bool => |value| !value,
            .Nil => true,
            else => false,
        };
    }
}

How would you create it with @Type() ? I did notice std.builtin.Type.Declaration exists in std.builtin.Type.Union but it only contains a name. Where would I specify the methods ?
Obviously I want to add more methods but adding a simple one as an example would be enough for me.

2

You cannot specify methods when you create types with @Type.
As alternatives consider either adding a function pointer or a pointer to a struct with your methods.

3 Likes
3

You can’t attach declarations to types generated with @Type, it is an intentional limitation.

The usual workaround is to create a wrapper type that you create using normal syntax instead of @Type that has the functions you want. But that only works if you don’t need to generate the functions, which most of the time you don’t, you can rely on reflection.

But if you do need to generate the functions, your only option is code gen.

The rational is to prevent generating overly complex types, comptime reflection handles the majority of use cases and if you need to, code gen is more friendly to tooling like zls.

2 Likes
4

This functionality is intentionally limited. For me, if I need to add declarations to a type created with @Type, I will simply wrap it in a wrapper struct and add the declarations in the wrapper.

pub fn Value(comptime T: type) type {
    const Inner: type = comptime blk: {
        const field_num = ??;
        var union_fields: [field_num]std.builtin.Type.UnionField = undefined;
        var enum_fields: [field_num]std.builtin.Type.EnumField = undefined;
        ... // fill union fields and enum fields
        const Tag: type = @Type(.{ .@"enum" = .{
            .tag_type = std.math.IntFittingRange(0, field_num - 1),
            .fields = &enum_fields,
            .decls = &.{},
            .is_exhaustive = true,
        } });
        break :blk @Type(.{ .@"union" = .{
            .layout = .auto,
            .tag_type = Tag,
            .fields = &union_fields,
            .decls = &.{},
        } });
    };
    return struct {
        u: Inner,
        pub fn isFalsey(self: @This()) bool {
            ...
        }
    };
}
3 Likes
5

Maybe you can attach a generated set of functions to a reified struct, after a fashion.
If “generated” is held to mean:

  • the number of functions, their names, and their implementations may be parameterized by comptime information
  • the function bodies themselves actually exist in your codebase, not generated at build-time

then you have the following pattern available to you (maybe, I haven’t tried):

In the comptime block defining your reified struct:

  • For every method you want to attach, implement it as the unique method (with some meaningless name like call, or maybe a meaningful name like @my_comptime_string if you really want) of some 0-bit struct, defined using true struct syntax
  • Add a field to your output struct for each of these mini method-structs, with type being the mini method-struct, name being the name you originally wanted for the method, and having a default value (only one is possible because 0-bit).
  • Go back and make sure that the implementations use @fieldParentPtr to make this work.

The effect would be that you can do

myReifiedStructInstance.method1.call();
myReifiedStructInstance.method2.call();
etc.;
1 Like
6

The idea was more to add these methods as a more convenient way of using the union. The body of these function would not be parameterized at compile time. Oh well. I guess I have a big refactoring ahead of me !

7

It sounds like their body is parameterized trivially in your case, so, my solution should work, and you even have the option in your case of doing

myReifiedStructInstance.methods.myUsefulMethod1();
myReifiedStructInstance.methods.myUsefulMethod2();
etc

If that API interests you, you can search for @fieldParentPtr