Hi,
Il 07/10/21 18:19, Zebediah Figura (she/her) ha scritto:
They don't behave exactly the same, though. In particular, compare_param_hlsl_types() will count "float" as equal to "float1", and "row_major float4x4" as equal to "column_major float4x4".
Ah, ok, didn't think of that. I am not sure that the compatibility of function overloads is regulated by an equivalence relation, so I am not sure this approach can really work, but I guess it's ok to postpone this problem until we want to really fix it (which probably means until we find a shader that depends on it).
Some brief testing suggests this is incorrect, though. Native will let you do this:
void func(float a) {}
void func(float1 a) {}
It will also accept "row_major float4x4" alongside "column_major 4x4". Even worse, though, it will accept "float4x4" alongside "column_major 4x4", "float" alongside "const float" alongside "volatile float", and even the following:
void func(float a) {}
typedef float myfloat; void func(myfloat a) {}
It won't accept "float" alongside "in float", though. That's too far. But it will accept "float" alongside "inout float" alongside "out float".
Of course, attempting to actually *call* func in any of these cases results in an "ambiguous function call" error. So it's not completely insane.
I think it is pretty insane anyway, especially given that even in the case of float vs float1 I don't think you have any mean at all to differentiate between the two. So, as soon as you define both of them, there is no way to call either, even with explicit casts.
Thanks, Giovanni.