[Question / proposal-maybe] resolving the @typeName of types in struct fields (eg. for ad-hoc/non-pkg-based sub-namespacing)

[metaleap]

Consider:

const std = @import("std");

const Group = .{
    .Type1 = enum{foo, bar, baz},
    .Type2 = union(enum) { a: u16, b: i16 },
};

pub fn main() void {
    std.debug.warn("{}\n", .{ @typeName(Group.Type1) });
    std.debug.warn("{}\n", .{ @typeName(Group.Type2) });
}

Output:

Group
Group

Not terribly critical in the current scheme of things, but would suggest as an "around-or-post 1.0 contributor-friendly rather-nice-to-have" longer-term to look into. (Or when self-hosting-comp is up and such subtleties / corner-cases become more immediately attackable.)

Or maybe it's just an accepted limitation of typeName, then feel free to close. Referencing in the field value another type name instead of anon/inline type-def "works" after all --- although then maybe typeName should rather act like with any other anon/inline type-def not ever anywhere named!

[JesseRMeyer]

Shouldn't the output be:

enum
union

(or more specialized variants thereof) ?

[metaleap]

Yeah what I would expect by default as of today --- although the other, "future proposal/suggestion" half of this issue would be whether to consider a (sugary, admittedly) Group.Type1 or just Type1 etc. Up for discussion. Given that structs are Zig's namespacing device, and that it is unlikely that any callers of @typeName "parse" its results (in the various forms) for extracting some specific meaning.. could be worthwhile + non-harmful.

[JesseRMeyer]

Not quite seeing the use-case. If you want the parent type, why are you asking about it from its members?

[metaleap]

A use-case? Here's a funky namespace of co-related struct types, to be sep'd out clearly from various other structs in the same .zig file (also not to be scattered into a different .zig file just for the namespacing purposes)

pub const OurApiSpec = .{
    .IncomingRequest = union(enum) {
        negate: fn (Arg(i64)) Ret(i64),
        hostName: fn (Arg(void)) Ret(String),
        envVarValue: fn (Arg(String)) Ret(String),
    },
    .OutgoingRequest = union(enum) {
        pow2: Req(i64, i64),
        rnd: Req(void, f32),
        add: Req(struct {
            a: i64,
            b: i64,
        }, i64),
    },
    .IncomingNotification = union(enum) {
        timeInfo: fn (Arg(TimeInfo)) void,
        shuttingDown: fn (Arg(void)) void,
    },
    .OutgoingNotification = union(enum) {
        envVarNames: []String,
        shoutOut: bool,
    },
};

(Above things sound silly because it's a demo/dummy/test setup for a protocol-handling lib that one then can use to also model real RPC protocols, not mock ones.)

Then later for logging / prints / tracing / compileError messages etc.pp. you want to see either OutgoingRequest or OurApiSpec.OutgoingRequest, not for all 4 types the same OurApiSpec.

[JesseRMeyer]

Ah, sorry. I got @typeof and @typename confused. I agree the ability to output the name of the identifier, and further context (like enclosing struct name, etc) associated with a type is important for Zig to provide. I don't know, but I would've thought that would be possible already.