Merge pull request #12 from seanchen1991/master

Add 2020-09-28 meeting notes

Author: yaahc

meetings/2020-09-28.md

@@ -0,0 +1,76 @@
+# Error Handling Project Group Agenda - 2020-09-28
+
+###### tags: `Error Handling` `Minutes`
+
+## Agenda Items
+
+- Prototyping an implementation of `std::core::Error` and stabilizing `#[feature(backtrace)]`
+- Identifying existing issues and RFCs that we should track
+    - https://github.com/rust-lang/rfcs/pull/2895
+- Planning for "Communicating best practices"
+- "How users expect error handling to be, As in, we take a leap into the future and assume all this was implemented into the language, then how it would potentially look"
+  
+
+# Meeting Minutes
+
+## Participants
+
+People in attendance:
+- Jane Lusby
+- Sean Chen
+- Ashley Mannix
+- DPC
+- Mukund Lakshman
+- Jakub Duchniewicz
+- must-compute
+- Lance Zhang
+- Oliver
+- Charles Ellis O'Riley Jr.
+- Kyle Strand
+- Lokathor
+- Jubilee Young
+
+## Topic 1: Discussing stabilizing `Backtrace` 
+- Global hooks vs Boxing vs a trait-based approach for stabilizing `Backtrace` in `core`.
+- Going with the trait-based impl for `Backtrace` in core.
+    - Private trait + public newtype wrapper. 
+    - Start with `eddyb`'s impl and see how many hooks are necessary along the way.
+- private trait with a public newtype wrapper
+    - newtype wrapper is an interface not subject to coherence so we can add new
+    methods without worrying about breaking changes downstream 
+- https://doc.rust-lang.org/stable/src/std/io/error.rs.html#67-71
+- trait-based approaches have fewer magic compiler pieces and so would be easier to put together
+- `write_backtrace_to(&mut dyn FormatterThing) -> Result<(),FormatterThing::Error>`
+    - ultimately about moving `Error` to core
+- should we do a trait object based solution internally with an unstable `Backtrace`
+  trait in core and a stable `Backtrace` type in core or should it use global hooks
+  like `panic_impl`
+- **need a prototype solution for exposing `Backtrace` as a type in `core` with the interface it currently provides in `std`**
+
+## Topic 2: What RFCs should this group be tracking?
+- This group will have its own Project board to track relevant issues/RFCs.
+- Prep status reports on relevant issues we're tracking for future meetings.
+- Pulled from the [tracking board](https://github.com/rust-lang/libs-team/projects/2#column-10224181)
+    - [#58520 tracking issue for error source iterators](https://github.com/rust-lang/rust/issues/58520)
+    - [#53487 tracking issue for RFC 2504, "fix the error trait"](https://github.com/rust-lang/rust/issues/53487)
+    - [#44838 tracking issue for RFC 2011: nicer assert messages](https://github.com/rust-lang/rust/issues/44838)
+    - [#2895 RFC: generic member access for dyn error trait objects](https://github.com/rust-lang/rfcs/pull/2895)
+- [#58520 tracking issue for error source iterators](https://github.com/rust-lang/rust/issues/58520)
+
+## Topic 3: Planning for "Communicating Best Practices"
+- Facilitate communication of best practices via a Book/documentation.
+    - Should include some guidance on FFI error handling.
+- Adding a book section to the project repo (using mdbook).
+- Publish *The Rust Error Book* (name subject to change) and potentially contribute to *The Book* to make its error handling recommendations consistent with what this group decides.
+
+## Topic 4: What is the long-term vision of what error handling in Rust looks like?
+- `Error` in `core`.
+- Stabilization of unstable `Error` interfaces.
+- Iterator API on `Backtrace`.
+- Generic member access (possibly with two-way flow).
+- Error return traces.
+- Some way to universally hook into all error reporting points for consistent error reporting.
+- Better handling of error enums
+- Guidance on FFI error handling.
+- Ways of recovering from recoverable errors.
+    - enum-convergance as errors propagate up the stack