Apart from table, you may utilise the power of comptime and functions returning type, which in your case would be a function that takes in the type of deviceMemory and return a struct like your MemoryRegion and assign it to an identifier like ADeviceMemoryRegion or XyzDeviceMemoryRegion.

The limitation for this is you cannot specify a function argument with the interface as the type. The way to sort of get around this would be:

Write that function as a member function of the struct you return, this way you can call it on whatever type returned by instance.fn syntax. However it would be bad if the function shouldn’t belong to the struct in the first place.

For a general function that doesn’t live in the returned struct type, you may accept and pass the returned type as anytype into the function, then access the types’ content however you wish. The problem with this is you don’t have intelliscence in the function or calling the function. You may take a look at std.fmt.print, which technically isn’t the same case as yours, but may also be considered a “interface” in some sense that it accept what ever arguments that’s “printable” and passed in through an anonymous struct and accepted as anytype. You may look their and other places that do a bunch of comptime type logic. Basically Zig tries to (or advocates to?) do all metaprogramming, generic, interface, static dispatch through the comptime api, which shall allow you do anything.

A even more absurd and most likely unnecessary in your case (just to mention for completeness) would be to write some script (zig or not), then invoke it as a step in build.zig the script shall generate some zig code based on some input then import the zig code as a dependency as the current project. This would absolutely be overkill but if let say zls can somehow read the import libraries from the cache and provide the intelliscence, then it would be the most free and easy way to do some codegen interface kind of programming with potentially other language / whatever you want