> Does that include ABI compatibility? For now, this is going to be tough to provide because of compiler bugs sadly (see #10208 and #10207). ABI stability is a broad topic which encompasses symbol names, whether the function is generic or not, implementation of a generic function, etc. For now, I believe the stability attributes are targeted at the signature of a method.
> Should it be an error to use lower stability internally? One of the goals will be to have the intrinsics module be #[experimental] or something other than #[stable], but this module is the basis of implementation for many other stable functions, so I believe that the module itself will have to opt-in to using the unstable intrinsic api, but the api provided by the module will still be stable. >> By default all nodes are *stable* - library authors have to opt-in to >> stability index tracking. This may end up being the wrong default and we'll >> want to revisit. > > Oh dear god no. `stable` should be *earned* over time, otherwise it's > meaningless. The compiler should treat untagged code as `unstable`, > `experimental` or a special `untagged` stability and accept that level > by default. One thing we should be sure to accomplish with this default is that you cannot use unstable apis by default. I imagine that an #[unstable] module can use #[unstable] functions, but perhaps #[unstable]-flagged items still have to opt-in to using other unstable items? > Requesting permission to spam the issue tracker with minor annoyances > we definitely don't want to live with forever. The C FFI <-> idiomatic > Rust bridge is especially painful. You may be interested in #11920 _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
