Generic types and source file structs

Help
21

Conclusion: the makeType(comptime T: type) idea is discouragable for the following reasons:

  • it’s definitely not idiomatic Zig; again, as linked in the docs above, TitleCaseTypeName (or PascalCase) is used for types, whether it’s a plain (struct, e.g.) type or it’s a generic (in which case the function name gets TitleCase because the function returns a type), or it’s a source-file struct, in which case the filename is capitalized, since it represents a named struct.
  • the makeType() scheme results in @typeNames that may be “fully qualified” (as in, foo.makeType(u8) (though awkward looking / non-ziggish), but the death knell is that language servers and debuggers might display only the shortened name, which would simply be makeType for all such (possibly totally different) types, which would be completely useless.

UPDATE: after I authored this summary, this was posted by @floooh, and is very attractive in its fulfillment of at least one of my hopes, without being as idiom-disobedient as my original proposal. Back to my original summary…

There is no way to get exactly what I was looking for, which I advertised as: the ability to use source-file structs with generic types; however, my proposal wasn’t exactly this, either, of course, since the function makeType() returned the struct, with its innards, rather than the struct’s members simply being file-level instead of nested. One of the objectives was to reduce the need to foo.Foo, and even to be able to assume the final type name of Foo (specialized), and that doesn’t look realizable. Rather, the standard

const foo = @import("foo.zig");
const FooX = foo.Foo(u8);

is really the only way. (Though One suggestion was made to reduce this to a one-liner equivalent, but you still have @import(“foo.zig”).Foo;- it’s definitely a valid point that addresses some of the hope.

1 Like
22

This dilemma is why I called the generic functions which return types Type() in my emulator project.

E.g. you stamp out a specific Z80 CPU type like this:

const Z80 = z80.Type(.{ .pins = Z80_PINS, .bus = Bus });

IMHO this would just look silly:

const Z80 = z80.Z80(.{ .pins = Z80_PINS, .bus = Bus });

…the implementation file is z80.zig and has the Type() function in the root scope:

pub fn Type(comptime cfg: TypeConfig) type {
...
}

The only thing I don’t like is the deep nesting level that’s introduced by this approach, e.g.:

pub fn Type(comptime cfg: TypeConfig) type {
    const Bus = cfg.bus;
    return struct {
        const Self = @This();

        fn or8(self: *Self, val: u8) void {
            self.r[A] |= val;
            self.r[F] = szpFlags(self.r[A]);
        }

…e.g. the actual code is 3 indentation levels to the right, haven’t found a good solution for this yet.

1 Like
23

Ah! Exactly! This is a perfect example of the use case; I’ve never taken an opportunity to look at your code… thank you.

So, this inspires a question: does this not suffer in the same way, where language servers and debuggers might contract this to merely ‘Type’, which wouldn’t be helpful if you had a bunch together? Perhaps you’re just willing to accept that.

Regarding indentation… I have an overly-simple thought for that, but only because, as is obvious, I like to explore outside the safe borders. :slight_smile: In this case only (that is, the case of, “A generic type that I’d like to make look as much like a source-file-struct as possible”), would it be acceptable to just:

pub fn Type(comptime cfg: TypeConfig) type {

const Bus = cfg.bus;

return struct {
    const Self = @This();

    fn or8(self: *Self, val: u8) void {
        self.r[A] |= val;
        self.r[F] = szpFlags(self.r[A]);
    }

It would only raise your reader’s eyebrows a little at at the very top. It puts const Bus on the left edge like members of a source-file-struct. It saves one indentation, which might be a more pleasant placement for the file overall. The very bottom of the file would also look slightly ugly. Anyway, I’d personally be inclined to post here to ziggit to see if people say that would be “barely acceptable” or “fine” or maybe “horrendous”… since I’m the guy who likes to know opinions like this, since I’m new, and trying to form some patterns that might endure :slight_smile: (big surprise).

24

Yeah I thought about just ignoring the intendation level and move everything to the left - but of course zig-fmt doesn’t like that and moves everything to the right again (I have enabled format-on-save in VSCode).

Disabling with zig fmt: off would need to go over the entire implementation which also isn’t really an option.

25

I see this opined, and I can’t bring myself to agree with it.

Possibly because I hold a certain interest in biology? Sometimes the genus and the species are the same thing, and that’s fine. There’s even word for it: it’s called a tautonym. Bison bison, Gorilla gorilla (and the subspecies, Gorilla gorilla gorilla (gorilla) (gorilla)), Gulo gulo (hail to the victors!), there’s a rather long list.

Embracing this evades the kind of foolishness which leads to std.ArrayList but std.array_list.Managed: this is, speaking plainly, bad taxonomy, arising from a mistaken understanding of how these things are supposed to work. τάξις is order, or arrangement, νόμος is law (kind of): there’s a science to it. Did we suddenly discover something Linnaeus was oblivious to? We did not, we’re ignoring the wisdom of our elders.

Namespaces nest, that forms a hierarchy, the only way to fulfill this oblivious “no classification” directive is to flatten everything out. Since that’s obviously bad, we’re stuck in, and may as well do it properly.

1 Like
26

Ah, right. Maybe there’s a little tension between the zen “Focus on code rather than style.” and zig-fmt. :slight_smile: Of course, as you say, one wouldn’t have to use zig-fmt.

1 Like