GHC2023 by nomeata · Pull Request #559 · ghc-proposals/ghc-proposals.
Rendered
This PR will guide the process of deciding if we want to have, and then defining, GHC2023, as per the process outlined in #372 .
Read in full here:
ghc-proposals:master
← ghc-proposals:joachim/ghc2023
> Is using intrinsics
I don't understand your question on intristics.
Anyw… ay, let me tell you more on intristics. First of all, there are two different concepts: intristics and language items. Both things are unstable low-level interface between compiler and user code (and usually this "user code" is standard library). Both things usually are useful for standard library developers only.
Intristics are special functions implemented in compiler. They have prototype, but they don't have body (because body is in compiler). They are similar to Haskell's primops, i. e. [GHC.Prim](https://hackage.haskell.org/package/ghc-prim-0.9.0/docs/src/GHC.Prim.html) module a. k. a. `compiler/GHC/Builtin/primops.txt.pp`.
Language items are in some sense opposite things. They are items (not necessary functions) implemented in user code (usually standard library), but which have special meaning for compiler. They are similar to Haskell's well known names (`compiler/GHC/Builtin/Names.hs`). More info on lang items is here: https://manishearth.github.io/blog/2017/01/11/rust-tidbits-what-is-a-lang-item/
In short, intristics are special functions (full list of such functions is hard coded in compiler), which can be _called from user code_ (usually std lib) and which are _implemented in compiler_. And lang items are special items (full list of such items is hard coded in compiler), which can be _called_ (and used in other ways) _in compiler_ and which are _implemented in user code_ (usually std lib).
In fact, things are even more complicated: sometimes the compiler ignores lang item's implementation and provides its own (for example, this is what happens for `impl Add for isize` as we know from Manish's article above).
How to use intristics? Ultimate low-level way to use intristics is write something like this:
```rust
extern "rust-intrinsic" {
pub fn volatile_load<T>(src: *const T) -> T;
}
```
Then you can call this intristic. You can write this `extern "rust-intrinsic"` construct (and then call the intristic) everywhere (i. e. in any crate). There is no any connection to standard library. This requires a nightly compiler. And you have to add "intristic" feature attribute.
There is slightly more high-level way to use intristics. All intristics are listed in https://doc.rust-lang.org/nightly/core/intrinsics/index.html module (in `core`), so you can simply import them from there. This requires nightly compiler and special attribute, too. And this can be done from everywhere, too.
(I can also tell you how to define and use language items, if you want.)
> guarding parts of library behind a feature toggle something only possible in `std` and `core`?
It seems yes. (In std, core, proc_macro and other standard crates.) They are implemented in standard library using `#[unstable(feature = "...", issue = "...")]` construct. I just tried to use this construct in my code and saw a message "stability attributes may not be used outside of the standard library"
This thread was posted by one of our members via one of our news source trackers.