Is your feature request related to a problem? Please describe.
Currently we have a 1:1 relationship between types and type converters. To support just the fundamental types, that is 40 required for just the vector types alone. Never mind adding on the matrix types. We need a better solution that means that more than one type can be handled by a type converter
Describe the solution you'd like
First up I want to change the name TypeConverter to ByteReader. It works better since we use ByteWriter in HLSL to talk about serializing. Secondly, we could have an extra id given by the user that can be passed into a byte reader in addition to the span of bytes. The byte reader can then use this to determine how to interpret the bytes. So we can have one byte reader interpreting multiple types. Easy. This will mean changing type_id to sometimes have this cookie and sometimes not (because sometimes there won't be a need for it if a byte reader is indeed meant for only one type). We can use expression SFINAE to determine if this extra cookie exists in HLSL
Describe alternatives you've considered
This is about the best I can come up with to reduce both the number of defines we send to HLSL and the number of byte readers.
Additional context
The sheer size of the commandline args that we send to dxc right now is a bit much. Additionally the amount of individual type converters that exist that are all basically doing the same thing is a bit much right now. So there needed to be a better way.
Is your feature request related to a problem? Please describe. Currently we have a 1:1 relationship between types and type converters. To support just the fundamental types, that is 40 required for just the vector types alone. Never mind adding on the matrix types. We need a better solution that means that more than one type can be handled by a type converter
Describe the solution you'd like First up I want to change the name TypeConverter to ByteReader. It works better since we use ByteWriter in HLSL to talk about serializing. Secondly, we could have an extra id given by the user that can be passed into a byte reader in addition to the span of bytes. The byte reader can then use this to determine how to interpret the bytes. So we can have one byte reader interpreting multiple types. Easy. This will mean changing type_id to sometimes have this cookie and sometimes not (because sometimes there won't be a need for it if a byte reader is indeed meant for only one type). We can use expression SFINAE to determine if this extra cookie exists in HLSL
Describe alternatives you've considered This is about the best I can come up with to reduce both the number of defines we send to HLSL and the number of byte readers.
Additional context The sheer size of the commandline args that we send to dxc right now is a bit much. Additionally the amount of individual type converters that exist that are all basically doing the same thing is a bit much right now. So there needed to be a better way.