|
| 1 | +- Feature Name: error reporter |
| 2 | +- Start Date: 2021-05-17 |
| 3 | +- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000) |
| 4 | +- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000) |
| 5 | + |
| 6 | +# Summary |
| 7 | +[summary]: #summary |
| 8 | + |
| 9 | +Specialization already works for concrete types, so we could |
| 10 | +specialize the `Termination` impl specifically for `Box<dyn Error>` |
| 11 | +today, there's nothing blocking this. That way we can confidently |
| 12 | +point people towards `fn main() -> Result<(), Box<dyn Error>>` knowing |
| 13 | +that it will output the right thing. :tada: |
| 14 | + |
| 15 | +# Motivation |
| 16 | +[motivation]: #motivation |
| 17 | + |
| 18 | +Currently all errors reported via the `Termination` impl on |
| 19 | +`core::result::Result` go through `Debug` instead of `Error`, which |
| 20 | +tends to be the wrong choice for errors. We have plans for fixing this |
| 21 | +via specialization but these plans are blocked on workarounds for a |
| 22 | +soundness issue and wouldn't even apply to `Box<dyn Error>` which |
| 23 | +_doesn't even implement the `Error` trait_. We cannot fix this as far |
| 24 | +as we can tell, but it turns out we probably don't need to for this |
| 25 | +specific case! |
| 26 | + |
| 27 | +# Guide-level explanation |
| 28 | +[guide-level-explanation]: #guide-level-explanation |
| 29 | + |
| 30 | +Explain the proposal as if it was already included in the language and |
| 31 | +you were teaching it to another Rust programmer. That generally means: |
| 32 | + |
| 33 | +- Introducing new named concepts. |
| 34 | +- Explaining the feature largely in terms of examples. |
| 35 | +- Explaining how Rust programmers should *think* about the feature, |
| 36 | + and how it should impact the way they use Rust. It should explain |
| 37 | + the impact as concretely as possible. |
| 38 | +- If applicable, provide sample error messages, deprecation warnings, |
| 39 | + or migration guidance. |
| 40 | +- If applicable, describe the differences between teaching this to |
| 41 | + existing Rust programmers and new Rust programmers. |
| 42 | + |
| 43 | +For implementation-oriented RFCs (e.g. for compiler internals), this |
| 44 | +section should focus on how compiler contributors should think about |
| 45 | +the change, and give examples of its concrete impact. For policy RFCs, |
| 46 | +this section should provide an example-driven introduction to the |
| 47 | +policy, and explain its impact in concrete terms. |
| 48 | + |
| 49 | +# Reference-level explanation |
| 50 | +[reference-level-explanation]: #reference-level-explanation |
| 51 | + |
| 52 | +This is the technical portion of the RFC. Explain the design in |
| 53 | +sufficient detail that: |
| 54 | + |
| 55 | +- Its interaction with other features is clear. |
| 56 | +- It is reasonably clear how the feature would be implemented. |
| 57 | +- Corner cases are dissected by example. |
| 58 | + |
| 59 | +The section should return to the examples given in the previous |
| 60 | +section, and explain more fully how the detailed proposal makes those |
| 61 | +examples work. |
| 62 | + |
| 63 | +# Drawbacks |
| 64 | +[drawbacks]: #drawbacks |
| 65 | + |
| 66 | +- many similar types with auto traits |
| 67 | + [programmerjake](https://github.com/rust-lang/project-error-handling/issues/40#issuecomment-840789700): |
| 68 | + `Box<dyn Error + Send>, Box<dyn Error + Sync>, ...` |
| 69 | + |
| 70 | +# Rationale and alternatives |
| 71 | +[rationale-and-alternatives]: #rationale-and-alternatives |
| 72 | + |
| 73 | +- Why is this design the best in the space of possible designs? |
| 74 | +- What other designs have been considered and what is the rationale |
| 75 | + for not choosing them? |
| 76 | +- What is the impact of not doing this? |
| 77 | + |
| 78 | +# Prior art |
| 79 | +[prior-art]: #prior-art |
| 80 | + |
| 81 | +Discuss prior art, both the good and the bad, in relation to this |
| 82 | +proposal. |
| 83 | +A few examples of what this can include are: |
| 84 | + |
| 85 | +- For language, library, cargo, tools, and compiler proposals: Does |
| 86 | + this feature exist in other programming languages and what |
| 87 | + experience have their community had? |
| 88 | +- For community proposals: Is this done by some other community and |
| 89 | + what were their experiences with it? |
| 90 | +- For other teams: What lessons can we learn from what other |
| 91 | + communities have done here? |
| 92 | +- Papers: Are there any published papers or great posts that discuss |
| 93 | + this? If you have some relevant papers to refer to, this can serve |
| 94 | + as a more detailed theoretical background. |
| 95 | + |
| 96 | +This section is intended to encourage you as an author to think about |
| 97 | +the lessons from other languages, provide readers of your RFC with a |
| 98 | +fuller picture. If there is no prior art, that is fine - your ideas |
| 99 | +are interesting to us whether they are brand new or if it is an |
| 100 | +adaptation from other languages. |
| 101 | + |
| 102 | +Note that while precedent set by other languages is some motivation, |
| 103 | +it does not on its own motivate an RFC. Please also take into |
| 104 | +consideration that rust sometimes intentionally diverges from common |
| 105 | +language features. |
| 106 | + |
| 107 | +# Unresolved questions |
| 108 | +[unresolved-questions]: #unresolved-questions |
| 109 | + |
| 110 | +- What parts of the design do you expect to resolve through the RFC |
| 111 | + process before this gets merged? |
| 112 | +- What parts of the design do you expect to resolve through the |
| 113 | + implementation of this feature before stabilization? |
| 114 | +- What related issues do you consider out of scope for this RFC that |
| 115 | + could be addressed in the future independently of the solution that |
| 116 | + comes out of this RFC? |
| 117 | + |
| 118 | +# Future possibilities |
| 119 | +[future-possibilities]: #future-possibilities |
| 120 | + |
| 121 | +Think about what the natural extension and evolution of your proposal |
| 122 | +would be and how it would affect the language and project as a whole |
| 123 | +in a holistic way. Try to use this section as a tool to more fully |
| 124 | +consider all possible interactions with the project and language in |
| 125 | +your proposal. Also consider how this all fits into the roadmap for |
| 126 | +the project and of the relevant sub-team. |
| 127 | + |
| 128 | +This is also a good place to "dump ideas", if they are out of scope |
| 129 | +for the RFC you are writing but otherwise related. |
| 130 | + |
| 131 | +If you have tried and cannot think of any future possibilities, you |
| 132 | +may simply state that you cannot think of anything. |
| 133 | + |
| 134 | +Note that having something written down in the future-possibilities |
| 135 | +section is not a reason to accept the current or a future RFC; such |
| 136 | +notes should be in the section on motivation or rationale in this or |
| 137 | +subsequent RFCs. The section merely provides additional information. |
0 commit comments