Currently, __traits(getAttributes, ...) does not work with types such as int. Now, no code is going to need to do something like __traits(getAttributes, int), because it's guaranteed that int isn't going to have any UDAs - no built-in type will. However, where it can become a problem is generic code, code that is dealing with types generically and involves checking for UDAs will have explicitly check for built-in types rather than feeding them to __traits(getAttributes, ...) like every other type. So, from a usability perspective and in the interest of types being treated consistently, __traits(getAttributes, ...) really should accept built-in types even if the result is always going to be empty.
Now, the reason that this proble exists is because - contrary to the expectations of most programmers - the language does not consider built-in types to be symbols, just keywords. It's the same reason why issue# 9029 exists. As I undarstand it, Walter has agreed to fix it so that alias parameters accept built-in types. Depending on how that is implemented, that may or may not automatically fix this. If the solution is to treat all built-in types as symbols in addition to keywords (which is what most folks would expect), then this issue will be fixed as well, but if the solution is to special-case alias template parameters so that they work with built-in types in addition to symbols, then this issue will remain unaffected.
This issue came up recently in D.Learn: http://forum.dlang.org/post/[email protected]
Comment #1 by robert.schadek — 2024-12-13T18:50:03Z