attachParentName() infinitely recurses on templated structs #3
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
If a System is a template instantiation,
attachParentNamewill be an infinite recursion.Tested with v0.1.1 and
50fa2ce19c.This patch does the job for the latest compilers:
I used __traits(fullQualifiedName, T) in the past. But since it doesn't work in betterC mode I came up with my simplified version which works also in betterC.
In general, this is used to generate names for components and systems when registering. Fully qualified name is used te prevent overwriting components/systems with same name but from different modules.
For some reason my code works fine if template struct has any function (it can be even an empty function with random name).
I've looked into fullyQualifiedName implementation and came up with other simple implementation which should fix your issue. For my test cases it gives me same outputs as fullyQualifiedName.
It might still has some corner cases I haven't tested. I would have to test it with my projects before merging.
Can you check branch 3-template-system-compilation-fail?
But that’s not true…
Sorry for late response.
Ohh, yes, my mistake. I was thinking about std.traits.fullyQualifiedName. fullyQualifiedName seems to be missing from __traits documentation.
I checked methods from discrod. typeid isn't uniqe (and throws compilation error in betterC).
mangleof gives uniqe name, but it doesn't look nice as name compared to fullyQualifiedName (and I believe that D changed it's mangling rules at least once in the past).
__traits(fullyQualifiedName, T) gives different results than fullyQualifiedName!T, and it isn't really unique for Templates (as template parameters aren't fullyQualifiedNames, just symbol name).
fullyQualifiedName is best but doesn't work in betterC.
My implementation gives same results as fullyQualifiedName. I recently fixed some cases in my implementation.
My plans for library were to implement API where your can specify name by yourself if you want. I'm using names for components in a way where those have to be stable across different language versions (storing names when serializing entities allowing for scene saving and hot-reload in my other projects)