Behaviour of @typeName()

Help
1

So i want to check whether two types are the same (one type is a runtime stored *const [:0]u8, where the other is a comptime “type” function argument) so basically this

pub fn isTheSame(self: Self, comtime x: type) bool{
    ///now i want to check if the comptime x of type is the same as the runtime stored type in self
    if  (self.described_type == @typeName(x)){
        return true;
    }
    return false;
}

I am uncertain whether this would work because here i am checking a pointer to the type name not the name itself, also i would like to not check the name character by character because this function will be invoked very often in a realtime application (although i know that checking even 100 character strings for equality is pretty much nothing for a modern computer)

2

Never rely on the output of @typeName: its return value will more than likely end up being implementation-defined (if @typeName isn’t removed from the language altogether, that is).

The issue with @typeName is simply that its behaviour (i.e. the string it returns) is necessarily implementation-defined and cannot be codified in a language specification, because we cannot reasonably standardise the compiler’s approach to generating names for types which don’t have an obvious user-provided name. The concern is that some codebases already use @typeName in a way which relies heavily on how our compiler generates type names, so in the future this would be likely to lead to Zig projects which do not compile on other compiler implementations, which is a bad experience for all involved.

https://codeberg.org/ziglang/zig/issues/32119#issuecomment-13988375

You can find typeid method from @mlugg in first link and it would be preferred way to do that. Copying it here for convenience:

const std = @import("std");

const TypeId = *const struct {
    _: u8,
};

pub inline fn typeId(comptime T: type) TypeId {
    return &struct {
        comptime {
            _ = T;
        }
        var id: @typeInfo(TypeId).pointer.child = undefined;
    }.id;
}

pub fn main() !void {
    @compileLog(typeId(u8) == typeId(u8)); // comptime-known
    @compileLog(typeId(u8) == typeId(u16)); // and works correctly
    @compileLog(typeId(u16) == typeId(u16));
    passAtRuntime(typeId(u8), typeId(u16));
}

fn passAtRuntime(a: TypeId, b: TypeId) void { // and you can pass them at runtime too
    _ = a;
    _ = b;
}
1 Like
3

Thanks a lot for the fast reply, to give a bit of background of what i am doing, Im trying to make a game engine, and currently writing some code to deal with storing collections of objects, because each object type has to be stored in a different collection. when researching i thought that the typeName approach is clunky, so i searched on the internet for a better solution and i found the discussion you linked to, but to be honest i didnt use it because i didnt like the weird code that it uses and chose to use typeName instead, but with the things you pointed out i think i will use the typeID solution though. I just dont understand why there isnt such a bultin as typeID

4

Seems like you doing something akin to ECS so here is also a link to type_id used for that kind of task. https://codeberg.org/Games-by-Mason/mr_ecs/src/branch/main/src/type_id.zig

5

thanks for the help, but i dont plan on making an ECS, its going to be something similar but not really.

2 Likes
6

I don’t think that typeids help a lot once you have a save/load cycle going on and changes to the codebase, because then you would need a mechanism to keep typeids stable or accurately update them from old typeids to new ones.

It seems to me that the most reliable is to have a sort of type registering api call somewhere where you manually associate some kind of unique name or id with a type and use that to deduplicate the types.register(name, type) calls (make them idempotent) so that they keep the stable id assigned by the types-registry between save/load-cycles, possibly erroring or migrating the data if the type has changed from the type that was registered previously. And to do that it needs to store enough information about the type that is registered so that it can do that, so basically runtime info about the structure of the type.

Once you have something like types.register you can let that return a typeid (like an index), so then you don’t really have a need for a magically generated typeid anyway.

So I think auto-generated typeids aren’t stable enough to be very useful across multiple recompiles, so once you need to save things they don’t help much. They could be part of some solutions but a somewhat less important part, like the current handle associated to a type.
Or for programs that don’t need to save and load things.

4 Likes
7

Check what DVUI does to generate ids (based on @src, if I recall).