Math.select - why not make the variable names helpful?

Hello!
Currently math.select in the Unity.Mathematics library takes ‘a’, ‘b’, and ‘c’…
How about the variables in the function get renamed on Unity’s side? It wouldn’t affect the output code at all, but it’d make things so much easier to remember. It’s kinda easy to remember that it’s the “same way as a lerp, but boolean”, but it’s also kinda easy to forget, 'coz it’s the opposite way round to a C# “?”, which is often what I’m converting from when moving over to Burst/Jobs/math. so, my suggestion is, instead of the relatively meaningless ‘a’, ‘b’ and ‘c’, it’s:

either:
math.select(float trueResult, float falseResult, bool condition)
or:
math.select(float f, float t, bool c)
or:
math.select(float f, float t, bool s)

basically anything that gives you the reminder that the first parameter is the one you’ll get on ‘false’, and the second one is the one you’ll get on ‘true’.

…while I’m here, it’d probably be good to change lerp from x,y,s to a,b,t (or a,b,s) - because, while it really doesn’t matter what letters we use here, x and y are pretty highly used & have a strong meaning associated with them.

well aware this doesn’t change my usage, my end code etc… - just would make things a lot clearer when trying to remember which order the parameters go in. - presumably there’s no genuine reason to not name these parameters?

1 Like

The naming is possibly related to how MSL material (6.4 relational functions) and OpenCL material reference the parameters as a/b/c, as they say they’ve made this API shader-like / familiar to shader writers. (HLSL 2021 has select with parameters in the same order as the ternary operator, which is great for adding to confusion.)

The genuine reason to not change parameter names is that renaming the parameters would be a source breaking change. It’s best not to make any breaking changes outside a major version change (2.x).

As a stopgap, consider enabling C# project generation for registry packages, which would enable seeing documentation for the method and its parameters in the IDE.

Struggling to see how it’d be a source breaking change, as the variables are only used by name inside the function… - but yeah, I guess MSL/OpenCL should consider better naming too!

Yes… but don’t forget named arguments at callsites.

Yeah - I mean, I had thought about that - but I’d be willing to bet that absolutely nobody would be doing that for meaningless variables called ‘a’, ‘b’ and ‘c’ on a math.select function with no optional parameters (for all the obvious reasons)… - but yes, in theory, sure. in practice, nah.