Tagged subtypes and method dispatch

[chqrlie]

Dispatching a method to specialized handlers defined for derived types is a classic object oriented feature that we must emulate in c2 with cumbersome switch statements such as this:

fn void Type.print(const Type* t, string_buffer.Buf* out) {
    out.color(col_Type);
    switch (t.getKind()) {
    case Builtin:
        BuiltinType.print(cast<BuiltinType*>(t), out);
        break;
    case Pointer:
        PointerType.print(cast<PointerType*>(t), out);
        break;
    case Array:
        ArrayType.print(cast<ArrayType*>(t), out);
        break;
    case Struct:
        StructType.print(cast<StructType*>(t), out);
        break;
    case Enum:
        EnumType.print(cast<EnumType*>(t), out);
        break;
    case Function:
        FunctionType.print(cast<FunctionType*>(t), out);
        break;
    case Alias:
        AliasType.print(cast<AliasType*>(t), out);
        break;
    case Module:
        ModuleType.print(cast<ModuleType*>(t), out);
        break;
    }
}

The pattern is so obvious that the code could be written automatically as if by a macro.

Thanks to the namespace isolation, the enum constants returned by t.getKind() could actually be identical to the type names, which would make the intent even more obvious:

type TypeKind enum u8 {
    BuiltinType,
    PointerType,
    ArrayType,
    StructType,
    EnumType,
    FunctionType,
    AliasType,
    ModuleType,
}

fn void Type.print(const Type* t, string_buffer.Buf* out) {
    out.color(col_Type);
    switch (t.getKind()) {
    case BuiltinType:
        BuiltinType.print(cast<BuiltinType*>(t), out);
        break;
    case PointerType:
        PointerType.print(cast<PointerType*>(t), out);
        break;
    case ArrayType:
        ArrayType.print(cast<ArrayType*>(t), out);
        break;
    case StructType:
        StructType.print(cast<StructType*>(t), out);
        break;
    case EnumType:
        EnumType.print(cast<EnumType*>(t), out);
        break;
    case FunctionType:
        FunctionType.print(cast<FunctionType*>(t), out);
        break;
    case AliasType:
        AliasType.print(cast<AliasType*>(t), out);
        break;
    case ModuleType:
        ModuleType.print(cast<ModuleType*>(t), out);
        break;
    }
}

This could be implemented with a dispatch table:

type fn void Proto_Type_print(const Type* t, string_buffer.Buf* out);

const Proto_Type_print[] Dispatch_Type_print = {
    [BuiltinType] = (Proto_Type_print*)BuiltinType.print,
    [PointerType] = (Proto_Type_print*)PointerType.print,
    [ArrayType] = (Proto_Type_print*)ArrayType.print,
    [StructType] = (Proto_Type_print*)StructType.print,
    [EnumType] = (Proto_Type_print*)EnumType.print,
    [FunctionType] = (Proto_Type_print*)FunctionType.print,
    [AliasType] = (Proto_Type_print*)AliasType.print,
    [ModuleType] = (Proto_Type_print*)ModuleType.print,
}

fn void Type.print(const Type* t, string_buffer.Buf* out) {
    out.color(col_Type);
    Dispatch_Type_print[t.getKind()](t, out);
}

I propose for the compiler to handle this automatically with a specific syntax:

fn void Type.print(const Type* t, string_buffer.Buf* out) {
    out.color(col_Type);
    [t.getKind()].print(t, out);
}

Whether the code generated uses a dispatch table, a switch statement or some other efficient scheme is an implementation choice depending on the number of enumerated types. Generating a switch statement allows the compiler to expand the code for the handlers inline for maximum efficiency and generate tests instead of a jump table if they are more efficient on the target CPU, thanks to jump prediction cacheing.

It might help to make the enum more explicit with an implementation type as type, but this does not seem necessary. The explicit (small) integer type helps cram it in a small corner of the base type, which could even be a scalar.

type TypeKind enum type {
    BuiltinType,
    PointerType,
    ArrayType,
    StructType,
    EnumType,
    FunctionType,
    AliasType,
    ModuleType,
}

[bvdberg]

I agree that all the current way requires quite a bit of typing. However, it is simple code and use (IMHO) one of the most powerful features of C-compilers: warn on missing enum cases. So if you add an enum case, the compiler will warn you about all the places you have to add it (provided there is no default case).

With a dispatch tables/mechanism, the function prototypes need to be the same, so the casts would have to happen in the functions themselves.

The syntax you propose looks a bit strange. You pass an enum type as an array index and that should become a dispatch table?
I think a construct like that would only be implementable nicely if relation between the types would be more explicit. So really an inheritance/implements scheme. But that doesn't quite fit the C(2) language

[chqrlie]

I agree that all the current way requires quite a bit of typing. However, it is simple code and use (IMHO) one of the most powerful features of C-compilers: warn on missing enum cases. So if you add an enum case, the compiler will warn you about all the places you have to add it (provided there is no default case).

This warning would of course be produced if not all enumerated types provide a type function with the specified name and argument lists (except the first argument, which must be a derived object). A syntax for a default case would be required in case a default behavior is intended.

With a dispatch tables/mechanism, the function prototypes need to be the same, so the casts would have to happen in the functions themselves. No, that would be counter productive. The cast is performed on the function pointer, which is risky unless the compiler can check for the presence of the base class. This is where having the compiler construct the dispatcher helps: no casts needed in the source code, yet type safety enforced automatically (provided t.getKind() return the actual canonical type of t or *t.

The syntax you propose looks a bit strange. You pass an enum type as an array index and that should become a dispatch table? I think a construct like that would only be implementable nicely if relation between the types would be more explicit. So really an inheritance/implements scheme. But that doesn't quite fit the C(2) language

Not exactly: t.getType() evaluates to an enumerated type (an enum value that is the name of a type) and [t.getType()] evaluates to the corresponding type, which is used as the base for the type function call:

    [t.getType()].print(out);

It is equivalent to an indirect type function call. The [] syntax is unambiguous and it looks a bit like the message sending system in other languages, except much more efficient. I like it better than this alternative: t.getType()->print(out);

If all methods are defined and return the same type, one could also write:

    return [t.getType()].getEndLoc();

or

    SrcLoc loc = [t.getType()].getEndLoc();

[lerno]

This is still talking about manually tagged types, right?

[chqrlie]

This is still talking about manually tagged types, right?

Yes t.getType() reads a bitfield and returns it as an enum. No RTTI as you have in C3.

[lerno]

There are no tagged unions in C3 (yet anyway), so not in C3 either (there is an any type though which does have pointer + typeid, but that's more for printf and such).

[chqrlie]

There are no tagged unions in C3 (yet anyway), so not in C3 either (there is an any type though which does have pointer + typeid, but that's more for printf and such).

I saw what you did in C3 for interfaces, it reminds me of the Objective C dynamic dispatch mechanism.

[lerno]

It is essentially Objective-C's dynamic dispatch. It solves the problem that it otherwise present with separate compilation. Something that Zig and Odin just ignores.

[bvdberg]

I still dont get how you propose to couple the enum type to the Types. I didn't see any syntax for that.

[chqrlie]

The enum names must be the same as the type names.