Introduce "safe" float comparison about handmademath

[bvisness]

Which functions are doing this?

[StrangeZak]

Actually these are just the Equals functions. So this warning really isnt valid, might wanna disable this warning on clang

[bvisness]

That sounds like the better option. I'd imagine this is rarely used anyway, and if it is, it's probably comparing to zero or something.

[RandyGaul]

You’re both right, comparing to known values (like exactly identity matrix) is about the only use case here. Anything beyond that and users will prefer to write their own custom little comparison inlined in their code.

I would actually recommend simply deleting the comparison function you have instead of silencing the warnings. It’s just a little extra bloat and not actually a useful function. But silencing isn’t a bad option either. It just means you’ll have more maintenance in terms of silencing warnings for updating or different compilers... So I would prefer to just delete it and not maintain the function at all.

[bvisness]

Do we have a matrix equals function?? We should definitely remove that. I can see a use for the vector case, but really only in the situation where you’re checking for zero. In that case I suppose checking each element is probably faster than getting the length (but I have not done any tests to verify that!)

[bvisness]

I know we’re not really living in crazy package land here, but in the interest of backwards compatibility, should we silence the warnings for now and remove the function(s) in a future major release? (Like maybe alongside handedness stuff.)

[RandyGaul]

Oh my mistake, I thought I was looking at matrix comparisons. I'm not actually sure how often people use vector comparisons. I never have myself 🤷‍♂

To check for all zeros in a vector I do dot(a, b) == 0, and write this inline. I've never had a case where I actually used a vector equal operator. In my own math header I use _mm_cmpeq_ps and _mm_cmpneq_ps simply because I happened to see these functions. I don't have any scalar overloads, so no warnings to silence. I'm actually probably going to just delete the == and != operators.

For deprecation there are a few options I can think of.

• Just delete function and make a note in the release notes on the breaking change.
• Use a macro to mark functions as deprecated, and print a note upon compilation. Then eventually delete the function, or move it to a separate deprecated section.
• The deprecated section could be an ifdef, or even just another header. For example, HandmadeMathDeprecated.h to be included after HandmadeMath.h is included.

[StrangeZak]

I’m all of option 2 this is what Unreal Engine 4 does. They say “Hey X function will be deleted in the next version” with a #warning and then remove it next version. Gives people time to update their usage of the library

[StrangeZak]

@bvisness Any opinions on what we should do here. Looking to close this ticket this weekend

[bvisness]

I think we should definitely silence the float comparison warning. The kind of bug it’s trying to prevent is just not applicable here. And I think we can go ahead and throw in a deprecation warning of our own, and plan to remove the operators/functions in version 2.0.

[StrangeZak]

Cool. I’ll push a fix sometimes today silencing this warning

[bvisness]

I'm torn on whether or not to delete the vector equals functions for 2.0. Unsurprisingly, we use them everywhere in the tests, so we'd have to reimplement them there. But the main reason I'm hesitant to delete them is that they're totally unambiguous, and not really any work to maintain.

At the moment I'd prefer to just silence the warnings and keep the functions around, even for 2.0. Feel free to change my mind!