Retire RFC 8 (intrinsics) without implementing it.

[brson]

This RFC changed the design of intrinsics with the goal of eliminating
the need for creating inlined wrappers around them. In the meantime,
the critical intrinsics for which this have been a problem have all
had their wrappers removed (afaik without solving the problem this
RFC set out to solve).

In the meantime, I decided I do not like the design here that unifies
intrinsics and lang items - they are sufficiently different to warrant
different names.

The ideas here have bitrotted and when we need to solve this for real
we should start over.

[lfairy]

I think this should include an explanation as to why it wasn't implemented, or at least a link to this PR.

[nikomatsakis]

Hear ye, hear ye. This RFC is now in final comment period until June 2nd.

[DanielKeep]

As an uninformed observer, I concur with @lfairy: the RFC text looks like a slam-dunk improvement, so it'd be nice to have a record as to why the RFC should be dropped.

From another perspective: there is (at least for me) a perception of RFCs requiring a good deal of rigour to be accepted. It'd be a little troubling if the core team could come along and nix an RFC after it's already been accepted and merged because "I do not like the design here". Having a concrete explanation added to the text would mitigate that. (Note: I'm not trying to imply anything by this, I just wanted to point out a possible point of future contention that occurred to me.)

[nikomatsakis]

It's always been the case that merely having an RFC be accepted is not a guarantee that the changes described therein will be implemented. From the RFC README:

Being 'active' is not a rubber stamp, and in particular still does not mean the feature will ultimately be merged; it does mean that in principle all the major stakeholders have agreed to the feature and are amenable to merging it.

In this particular case, the topic at hand (intrinsics) are considered an unstable part of Rust. The fundamental ideas in this RFC may still be good (though in re-reading the RFC I found it rather vague in many details), but enough time has elapsed that when it comes time to "stabilize" intrinsics, it's probably best to write a fresh RFC at that time. Basically, it's a good idea to have the design phase and the implementation phase be close enough together that people can still remember the details! So on those grounds alone I think @brson is probably right that it's a good idea to just "deprecate" the RFC and revisit it later.

[nikomatsakis]

This RFC is considered accepted. Per the comments, I added some additional explanatory text explaining that while the design may be a useful starting point, it should be revisited in light of all the time that has passed.

--- Language Design Subteam