-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move comparisons to traits #265
Conversation
Apologies, I am not trying to ignore this, I just was getting sidetracked by an Adventure or two. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
we should post somewhere users will notice that this breaks API compatibility. |
Okay. Having reviewed this properly, I feel like the ergonomics of these ops could probably be improved further and I think we will eventually find we want to encode the idea of associated masking types in a separate trait, as it feels plausible masked ops will want to not have to depend on SimdPartialEq being defined, but having said that I see no reason not to merge this as it stands as it is a significant improvement. |
A simpler variant of #206.
SimdPartialEq
,SimdPartialOrd
, andSimdOrd
. The function names are prefixed withsimd_
to disambiguate from the regularPartialEq
etc functions. With the functions on traits instead ofSimd
directly, shadowing the function names doesn't work very well.Ord
-like functions are put into aSimdFloat
trait. The intention is that eventually (some time after this PR) all floating point functions will be moved fromSimd
toSimdFloat
, and the same goes for futureSimdInt
/SimdUint
traits.