We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
rawOp
_op
The problem with prefixing it with "unsafe" or "raw" makes stuff super verbose.
And results in inconsistencies like toWadUnsafe vs unsafeMulWad; which I understand is because unsafeToWad just sounds werid.
toWadUnsafe
unsafeMulWad
unsafeToWad
The _op nomenclature has been used in SIMD intrinsics like _mm256_xor, and feels more natural.
_mm256_xor
With this renaming, we can have stuff like _expWad, _lnWad, without feeling awkward.
_expWad
_lnWad
Still, there are some advantages of "raw" prefix:
I'll probably leave this up for a few weeks before deciding.
Most probably will stick to no change.
The text was updated successfully, but these errors were encountered:
I don't like safe and similar that want to add some semantics but not super verifiable (so, it's like "why").
safe
++ on _op or similar more functional term.
Sorry, something went wrong.
No branches or pull requests
The problem with prefixing it with "unsafe" or "raw" makes stuff super verbose.
And results in inconsistencies like
toWadUnsafe
vsunsafeMulWad
; which I understand is becauseunsafeToWad
just sounds werid.The
_op
nomenclature has been used in SIMD intrinsics like_mm256_xor
, and feels more natural.With this renaming, we can have stuff like
_expWad
,_lnWad
, without feeling awkward.Still, there are some advantages of "raw" prefix:
I'll probably leave this up for a few weeks before deciding.
Most probably will stick to no change.
The text was updated successfully, but these errors were encountered: