# Libs Meeting 2020-10-15

###### tags: `Libs Meetings` `Minutes`

https://rust-lang.zulipchat.com/#narrow/stream/259402-t-libs.2Fmeetings/topic/.5Bregular.20meeting.5D.202020-10-14

## Agenda

### Project group updates

- Error handling: https://github.com/rust-lang/libs-team/issues/3
- Stabilizing `backtrace`: https://github.com/rust-lang/rust/pull/72981
- Portable SIMD: https://github.com/rust-lang/libs-team/issues/4
- Most work is happening here: https://github.com/rust-lang/stdsimd
- Plan for getting code into `std`

### The 2021 edition

- Did we want to make prelude changes? Anything else?

### Merging `std` / `alloc` / `core`

- This has come up in the Error handling group and in Portable SIMD as being desirable.
- Do we want to do this? Any clear blockers to consider first?

### RFCs

- Safer transmute: https://github.com/rust-lang/rfcs/pull/2981
- jwrenn can walk us through it. There's a lot of API surface area but a small MVP
- Reading into uninit buffers: https://github.com/rust-lang/rfcs/pull/2930
- Governance: https://github.com/rust-lang/rfcs/pull/2979

### Timing

- Are we happy with this time-slot and format?
- Did we want to roll triage in to this too with `I-nominated`?

## Summary

### Updates on project groups

Both are moving along nicely. Both have raised the `std` merger as something they want to do.

### Backtraces

We can `core`-ify the backtrace API if we want. Having a pluggable backtrace API is useful for other cases too where you might be embedded in a different language runtime.

Doing this doesn't really need to block stabilization though, and never really did. We already can't move `Error` to `core` because it has impls on `Box` that would be incoherent.

We can try stabilize the `Backtrace` type independently of the methods on `Error`. Would that be enough for `anyhow` to support backtraces?

There's a need to move forwards with this so that users who currently can't use backtraces after migrating off `failure` can start doing it.

### Merging

Merging `core` `alloc` `std`: need to actually figure out what this needs.

### Prelude

2021 prelude: what are the possible breakage vectors for changing the prelude? New trait methods. A lint that covers `TryFrom` and `TryInto` should also cover similar changes in other editions.

Super-trait item shadowing might be related, but the breakage here doesn't come from sub-traits.

We already use priority for name resolution (where glob imports are considered lower priority), but not for method resolution. If we do start doing that then we could make prelude additions without breaking. It would also deal with breakage that comes from new unstable methods in `nightly`.

### Safer transmute

We spent the bulk of the meeting exploring the _Safer Transmute_ RFC.

Some questions around what `Here!()` is and how it works. It's a purely opaque type that doesn't have any subtyping relationship based on visibility. It's only useful for transmuting, even though it can technically be used for other things.

There's some skepticism of the `Here!()` macro intentionally subverting coherence. It's working against traits.

We couldn't come up with better names than _PromiseTransmutable*_ and using `#[derive]` seems to make sense because we do imagine these traits will need to be manually implemented sometimes.

### What's next

We'll do some triage in the next Libs meeting.