# PEH Meeting Agenda - 2020-10-12

###### tags: `Error Handling` `Minutes`

- [2020-09-28 Meeting Minutes](https://hackmd.io/th5k9_pBRBGmpgnFWJzUHw?both)

## Action Items

- Implement trait based proof of concept for `Backtrace` in `core` (Jane Lusby)
- Setup `The Rust Error Book` (must-compute, Charles Ellis O'Riley Jr, and Jakub Duchniewicz)
- Draft a [blog post](https://hackmd.io/GMLcORX_R7W4de0ZryDIxg?view) detailing the long-term vision of what this group thinks Rust error handling should look like (Sean Chen)
- Status Updates on Tracked issues (What's the current status, what are the next steps, what are the blockers, is it actively being worked on)
- [Generic Member Access](https://github.com/rust-lang/rfcs/pull/2895) (Jane Lusby)
- [Fix the error trait / Stabilizing Backtrace](https://github.com/rust-lang/rust/issues/53487) (Jane Lusby)
- [stabilizing error source iterators](https://github.com/rust-lang/rust/issues/58520) (Oliver)
- [Box error alias](https://github.com/rust-lang/rfcs/pull/2820) (unassigned)
- [stabilizing Error::type_id](https://github.com/rust-lang/rust/issues/60784) (Jakub Duchniewicz)
- [PanicInfo::message](https://github.com/rust-lang/rust/issues/66745) (DPC)
- [nicer assert messages](https://github.com/rust-lang/rust/issues/44838) (Charles Ellis O'Riley Jr.)
- Moving forward with adding an iterator API to `backtrace` (Sean Chen)

## Agenda Items

- Review action items from last meeting
- Review open issues on project group repository
- Anything to buble up to the Libs meeting?

# Meeting Minutes

## Participants

People in attendance:
- Jane Lusby
- Sean Chen
- Ashley Mannix
- Kyle Strand
- Lance Zhang
- Jeremiah Senkpiel
- Jakub Duchniewicz
- DPC
- oliver
- Charles Ellis O'Riley Jr.
- must-compute
- Jubilee Young

## Backtrace in core

- So far the implementation is moving forward fine, but there are questions around the hooks
- Not clear how to set them up with a default in `no_std` so users don't _need_ to write one like `#[panic_handler]`
- Current work in progress [here](https://github.com/rust-lang/rust/pull/77384)
- There's enough sketched out that it shouldn't be a blocker for stabilizing `backtrace` anymore

## The Rust Error Book

- We now have a folder in the `project-error-handling` repository for content

## Log-term project group vision and goals

- Draft here: https://hackmd.io/GMLcORX_R7W4de0ZryDIxg?view

## Generic member access RFC

- There's an updated API in `object-provider` that the RFC would like to use
- Once the content is updated it needs some Libs input
- There could be some tie in with `tide`'s `Response` type?

## Fix the `Error` trait / Stabilizing `backtrace`

- Covered in the earlier discussion on _Backtrace in core_
- There could be some documentation work to do on `backtrace`

## Stabilizing `Error` source iterators

- stabilizing error source iterators
- trait objects vs. provided methods
- [stabilization report 2020-09-14](https://github.com/rust-lang/rust/issues/58520#issuecomment-691982191)
- unergonomic use-cases ---> difficulties stabilizing
- bugs
- blocked on [#53487](https://github.com/rust-lang/rust/issues/53487)
- [#75180](https://github.com/rust-lang/rust/pull/75180) might feed into this too
- related crate [`error-chain`](https://crates.io/crates/error-chain)

## Stabilizing `Error::type_id`

- Several possible approaches, but all are waiting for other stabilizations/RFCs
- #[marker] trait stabilization: https://github.com/rust-lang/rust/issues/29864
- negative trait impls
- dynamic vtable type_id (like C++ typeid keyword) https://github.com/rust-lang/rfcs/pull/2580
- final keyword -> no overriding of trait any more
- new trait TypeInfo https://github.com/rust-lang/rfcs/pull/2738
- Not clear it's something we want to stabilize
- Looks like a rabbit hole we don't want to go down right now

## `PanicInfo::message`

- No progress made here

## Nicer Assert Messages

- [RFC](https://github.com/rust-lang/rfcs/pull/2011) has been approved, with no implementation started yet
- Does this need to be implemented using the compiler's built-in proc macros, or can it be done as an external crate using `pro-macros` and `syn`?
- Need external thoughts/mentorship on this question

## Iterating over `Backtrace` frames

- Just starting out, so there hasn't been much discussion yet
- The `backtrace` crate has a `frames()` fn that already exposes its individual frames
- We could propose basically the same thing for `std`'s `Backtrace` type

# Outcomes

## Backtrace in core

- @KodrAus to ping https://github.com/rust-lang/rust/pull/72981 and raise at Libs meeting RE `backtrace` stabilization

## Long-term project group vision and goals blog post

- @Jane Lusby @Jakub Duchniewicz @KodrAus to review draft content

## Generic member access RFC

- @Jane Lusby to incorporate changes from `object-provider`
- @KodrAus to review RFC and ping Libs

## Stabilizing `Error` source iterators

- Looks like many parts of this are stuck on fixing the `Error` trait, so our efforts should be focused here to push this forward

## Stabilizing `Error::type_id`

- Putting this one on the back burner

## Nicer Assert Messages

- Look into whether we can implement an external POC for this ourselves
- Need external advice/mentorship (possibly from t-libs-impl) before we can get started on it

## Iterator API on Backtrace

- @Sean Chen to look more into this initiative
- Export an identical `fn frames(&self) -> &[BacktraceFrame]` to `std`
- Add it as an unstable API to `Backtrace` without an RFC to start with (just an FCP on the implementation itself)