Introduce trait-driven arithmetic

[workingjubilee]

This allows collapsing 5~10 instances of a function on the Simd type
into 1-3 copies, at least from the perspective of the docs.
The result is far more legible to a user.

Left deliberately unfinished to offer a taste of the difference
and allow the comparative angles to be discussed.

[jyn514]

@workingjubilee FYI the rustdoc team has considered dividing up the sidebar by impl blocks, with some summary of the impl bounds between each, which might be a nicer way to solve this problem without making the API more complicated in order to improve the docs.

[calebzulawski]

@jyn514 would that perhaps cover the many duplicate entries in search, too? Fixing it in rustdoc, rather than an API change, might be my preference.

[jyn514]

@calebzulawski I haven't thought about search. Can you open an issue on rust-lang/rust?

[calebzulawski]

Opened this issue: rust-lang/rust#90929

[workingjubilee]

IMO this shouldn't complicate the API much (this rough pass does a little, but I think a better version would be somewhat simpler, this is basically just a proof of concept), but I am definitely open to comparing alternatives here.

[jyn514]

@workingjubilee gotcha - this may make sense to merge in the meantime then, I don't know how long it will take to improve this on rustdoc's side.

[workingjubilee]

Then given that the docs right now are actively crashing user's browsers, this gets to move to the head of the line.

[calebzulawski]

Regular rustdocs for std can crash the Android browser, which is what I'm guessing what's going on. I've had it happen for various crates, too...

[workingjubilee]

Yes, and there has also been work on minimizing that from the rustdoc team. My phone can usually open Iterator now.

[workingjubilee]

This does not eliminate the problems (there is also the matter of the explosive number of trait implementations!) but it makes things palpably lighter in terms of method documentations.

from_ne_bytes and to_ne_bytes deserve their own PR for various reasons.

[workingjubilee]

This PR knocks off about 500kb for the primary Simd type's page.

[calebzulawski]

I'm still confident that, if we go this route, the traits should be broken up entirely by function or function category, and not Int etc. I also think the traits should be implemented on the scalar, not the vector.

[workingjubilee]

I also think the traits should be implemented on the scalar, not the vector.

That unfortunately doesn't really work when the function needs to be differently dispatched based on the trait implementation. None of the examples you cited in comparisons.rs require dispatching like that, which is why I didn't always do that.

[calebzulawski]

I'm confused--you did some of them that way, so why not all?

[workingjubilee]

The ones I could do that way, I did,
and the ones that I could not do that way, I did not.

[workingjubilee]

Closing this in favor of carving this up into other discussions like in #198.