Proposal: ability to set type name directly in containers.

[tgschultz]

Zig's ability to generate new types at comptime is an incredibly useful tool, however, in all but the simplest of cases it quickly leads to unreadable type names:

error: no member named 'readFn' in struct 'std.io.OutStream(*const std.os.file.Streams,fn(*const std.os.file.Streams, []const u8) @typeOf(std.os.file.Streams.writeFn).ReturnType.ErrorSet!void)'
                .readFn = writeFn,
                ^

I've personally seen recursively generated types with names several lines long. As one of zig's fundamental tenants is readability and clarity, it would be useful to clean these up. It is unlikely that the compiler can make decisions in this regard that will be adequate for all use cases.

I propose allowing the programmer to set the type name directly from within the container's scope. Let us imagine a new builtin: @setTypeName(comptime name: []const u8).

pub fn OutStream(comptime S: type, comptime WriteFn: type) type {
    return struct {
        @setTypeName("OutStream(" ++ @typeName(S.Child) ++ ")");
        const Self = @This();
        
        impl: S,
        writeFn: WriteFn,

        pub fn write(self: Self, bytes: []const u8) !void {
            return self.writeFn(self, bytes);
        }

        //......

    };
}

Would then display as:

error: no member named 'readFn' in struct 'std.io.OutStream(File.Streams)'
                .readFn = writeFn,
                ^

Drawbacks that spring immediately to mind are that this increases the risk of naming conflicts, and could obscure the source of the type.

[daurnimator]

Would this get prefixed with the module name? E.g. io.

[tgschultz]

That sounds like a good idea, yes. I've updated the example.

[daurnimator]

The OutStream is implicit too: maybe you should only get to modify the bit in parenthesis?

[tgschultz]

I don't think that would cover all use cases. Consider the comptime Pseudo-Struct, where base names would end up being FieldFn or impl.