I guess there shouldn't really be a notion of ipairs on it, then. Unless the format does have a sensible end? Either way, it feels more like a function actually-- decodeTileInfo or whatever. Ykwim?

There definitely is a logical "end" - the attrs table stores attributes about each enum item, and there are a fixed number of those. That's what my comparison to the behavior of @df.item_type was intended to demonstrate - ipairs() on an enum does end.

However, the Lua layer (maybe also C++) has a "default" attributes object for any enum items that aren't defined, which also includes values past the end of the enum. Here's another example. 1 and 2 are valid item_types, but 999 and 9999 are not, and the last two refer to the exact same table.

[lua]# !df.item_type.attrs[1]
<item_type._attr_entry_type: 0x7ffff7dcf430>
[lua]# !df.item_type.attrs[2]
<item_type._attr_entry_type: 0x7ffff7dcf448>
[lua]# !df.item_type.attrs[999]
<item_type._attr_entry_type: 0x7ffff7dcfca0>
[lua]# !df.item_type.attrs[9999]
<item_type._attr_entry_type: 0x7ffff7dcfca0>

So while we do want invalid indexes to continue to work, we should make ipairs(some_enum.attrs) stop at the same place as ipairs(some_enum) to fix this.