Add a compile time table construct/ X-macro (C) approximation

[alexgorcrom]

Idea

One of the very useful C constructs that can be created using macros is the so called X-macro that allows the maintenance of many related pieces of data effectively in a single table in a single place and if new data needs to be added this is easily done and will then be propagated across the whole codebase without having to explicitly do much (in most cases). An example of this sort of pattern would be something like:

/* X(upper, lower, file_name, x, y)
#define DIRECTION_ARROWS \
    X(NORTH, north, "north_arrow.png", 0, 1) \
    X(SOUTH, south, "south_arrow.png", 0, -1) \
    X(EAST, east, "east_arrow.png", 1, 0) \
    X(WEST, west, "west_arrow.png", -1, 0)
    
enum direction_arrow {
#define X(upper, ...) DIR_ARROW_##upper,
    DIRECTION_ARROWS
#undef X
};

const char *get_arrow_name( enum direction_arrow dir ) {
    switch( dir )
    {
#define X(upper, lower, ...) case DIR_ARROW_##upper: return #lower;
    DIRECTION_ARROWS
#undef X
    }
}

const char *get_file_name( enum direction_arrow dir ) {
    switch( dir )
    {
#define X(upper, lower, file_name, ...) case DIR_ARROW_##upper: return file_name;
    DIRECTION_ARROWS
#undef X
    }
}

...

With the above if the North West direction is added the enums and functions that depend on the X macro will be automatically updated and the new values will be consistently managed. This pattern is incredibly useful especially in embedded situations.

If this were to be turned into a language feature this would map closest to a compile time relational table.

I would imagine that in Odin this could look something like:

DirectionArrows :: table{arrow_name: string, file_name: string, x: f32, y: f32} {
    North{"north", "north_arrow.png", 0, +1},
    South{"south", "south_arrow.png", 0, -1},
    East{"east", "east_arrow.png", +1, 0},
    West{"west", "west_arrow.png", -1, 0},
}

In addition to the user defined fields there would be two implicit ones KEY and NAME, KEY being the entry id and NAME being the string of the table key, i.e. North and South in the above example. The relevant column would then be accessed something like: .North.file_name. Many of the existing constructs could be used as if this were an enum.

Issues/Similarities

Enums

In the case where a user does not specify any additional fields (kind of against the point of such a construct) this basically degenerates into an enum

Enumerated Arrays

Functionally this end up providing the same resulting behaviour as the enumerated arrays and is more restricted - in particular it cannot be partial (this I would consider a benefit) as it does not make sense to have a partial table of this type.

I guess this would essentially be syntactic sugar for:

DirectonArrow :: enum{ North, South, East, West, }

DirectionArrow_TableEntry :: struct{ arrow_name: string, file_name: string, x: f32, y: f32 }

DirectionArrow_Table :: #soa[DirectionArrow]DirectionArrow_TableEntry {
    .North = DirectionArrow_TableEntry{ "north", "north_arrow.png", 0, +1 },
    ...
}

Given that it would be syntactic sugar of the above, it means that the same rules could be used to extend it by a user of the table as the enumerated arrays, i.e.:

DirectionArrows_Ext :: [DirectionArrows]<type> {
    .North = <initializer>,
    ...
}

The main benefits that I see of such a type would be that when the type is passed around the "default" enumerated array associated with the internal enum would be implicit when fields are being accessed from a proc() and it keeps all the data in once place, quite tightly packed, whereas the expansion of it is more code to look through (not the biggest of issues - granted)

[gingerBill]

I understand the desire for the macro, but it's not going to happen, sorry.

The best solution at the moment is doing the enumerated array thing, which does at least make sure you cover all the cases.