treat intrinsics entirely as an implementation detail of specialized modules

[thestinger]

Exposing all of the intrinsics in one module is much more convenient than ad hoc extern blocks all over the standard library, but is very annoying for users of low-level Rust. It would be much nicer to treat intrinsics as part of the library API, and expose them in relevant modules. The fact that the API may be an intrinsic and not a library defined function is an implementation detail. Safe intrinsics should not be exposed as both an unsafe function and a safe wrapper.

Example: https://github.com/thestinger/rust-core/blob/master/core/f64.rs

[Thiez]

This sounds like the opposite of #3369. Or do you mean keeping the intrinsics in intrinsics.rs but making it private, and reexport them in the relevant modules?

[thestinger]

It's not the opposite of #3369. We used to re-declare them whenever they were needed, rather than exporting them in a single time in a relevant module. I'm not proposing we go back to how things were before.

The rust-core library is mostly (some numerics stuff is still in intrinsics) doing it as a single export location for each intrinsic along with some of them having a wrapper to give them a saner name or mark them as safe. It makes things much simpler for users of the standard library, such as the standard library itself.

[thestinger]

This provides a measurable compile-time performance improvement, and also a runtime performance improvement at --opt-level=0 and --opt-level=1 if the wrappers aren't #[inline(always)].

I think the only thing we need to do is make sure rustdoc reports exported intrinsics the same way as it does Rust functions.

[thestinger]

We should also feature-gate extern "rust-intrinsic" {} and #[link_name = "llvm.*] in order to completely hide these as implementation details.

[pnkfelix]

assigning to non-1.0, P-low.

[brson]

Intrinsics are feature gated, the intrinsics module is unstable with no current plans to stabilize. I believe the current situation is fine.