I wonder if UserStats would be more aesthetically pleasing? I guess this could conflict with a separate struct just called UserStats in Swift.

More work but I think we could use TS namespaces here as well:

export namespace User {
    export interface Stats {
    }
}

I believe that this will automatically merge with the interface Player, if it exists.

Hey William, on the naming - yeah, UserStats would read nicer, but as you noted it could collide with an actual UserStats struct. The underscore keeps it unambiguous and mirrors the internal ABI name and aligns with current approach elsewhere in the code.

As for TS namespace idea - we do already emit namespace blocks in the declare global path (for exposeToGlobal: true), so the mechanism exists and could be reused. Current approach aligns with use of underscore in other places, but that could be considered, depending on @kateinoigakukun preference.

I think it makes more sense to use TS-namespace to represent the hierarchical types for public user-facing APIs.

Updated - nested struct interfaces now use TS namespaces. User.Stats and Player.Stats generate:

export namespace User {
    export interface Stats {
        health: number;
        score: number;
    }
}
export namespace Player {
    export interface Stats {
        level: number;
        rating: string;
    }
}

Internal JS struct helpers still use underscore-separated keys (structHelpers.User_Stats) since those aren't user-facing.