Burst doesn't support nameof(TType) at the moment (it returns TType no matter what TType actually is at a particular callsite). By looking at the ECS forum, a lot of bursted code seems to leverage generics to avoid paying runtime costs on generalizations, so this would already be useful for logging purposes at a minimum. More interestingly, in systems/cases where you don't care that much about the perf hit this can create if used poorly, it'd enable adding per-type data to a system during initialization. There's some interesting things you could do with this. The gist of it would be: Have a RegisterTypeWithSystem<TType> function that passes some data that the system internally associates with the type. This data can vary based on the system, but you can imagine things like: "Use this allocator for all internal allocations you make related to this type" "Take this function pointer that defines a behaviour for this type" (this is not necessarily a good thing to do all the time, but it can be useful in some cases) "Here's some per-type blob data that you'll need to have in order to work correctly with this type" I currently use this to setup some of my job-management stuff (I do this to gather job-scheduling data to generate a view of running job-graphs). I wanted to use this to setup the size of serialization buffers for specific systems to use in my rollback engine. Etc... Have jobs and/or bursted functions with the form burstedSystem.DoSomething<TType>(ref TType) that leverage nameof(TType) and the system's internal state (typically, maps of type to internal state handles/pointers) to actually do things. When I say system, I don't mean just Unity ECS systems. I mean any custom system a game may have that'll run bursted jobs. I've played around with C# Source Generators and, for certain use-cases, I don't mind the perf hit at all just so that I don't have to deal with them (too much setup required for my taste + horrible debugging experience). Given the time and maintenance headache they are, I'd rather just take the perf hit. In my use-cases and tests (outside of burst-land with GetType().FullName instead), the perf impact has been negligible. This request is not really about any specific use-case for this --- whether or not you'd want this is very problem-specific anyway. However, I got the impression that this would enable use-cases that you currently have no choice but to go to Source Generators (which is heavy on the dev cost side due to the bad dev environment) or live with some error-prone boilerplate (which can be manageable but scales poorly with respect to team-wise). Based on that and the logging case, I think there's a case for adding support for this. I'm no compiler expert too so, if there's a reason this can't/won't be done for both JIT and AOT, I'd love to know that is the case and learn why that is the case.