One of the biggest benefits of Rust is that it allows API authors to use the type system to enforce domain invariants at compile time.
However, currently compiler errors only convey the reason for the error from the language perspective (ownership, borrow checker, etc.). They don't help with explaining WHY the author may have chosen to use self vs &self. As a result, a lot of people, even those who aren't so new to Rust, may feel like the language is being unnecessarily complex (i.e. fighting the compiler) instead of grateful that the compiler stopped them from doing something wrong.
I think it would be really nice to allow us to annotate functions with a macro to allow us to hook into certain compiler errors to add custom messages.
E.g. Trying to do file.read() after you called file.close already currently just yells at you about ownership. With this feature, the File::close() function could be annotated with a macro specifying that if there is a use after move error for self, it should also say "File handles shouldn't be read / written to after they have been closed."
I think this would be useful, not just for conveying that Rust's rules are often there for good reason, but also to clarify the kinds of things Rust's affine type system can be used for instead of just memory safety / systems programming stuff.
I had a related idea recently for traits. Because they encode behaviour, having an error message explaining the value not satisfying a trait bound is described in behaviour terms may be helpful.
For example, imagine some trait ToFoo. Maybe there could be some annotation like "converts to a Foo", and errors could read something like "i32 cannot be converted to a Foo" before the usual trait bound unsatisfied error.
It's possible this could be extracted from the doc comment if formatted in a certain way.
Maybe all of this is just wishful thinking. Food for thought, at least.
Within the compiler (and in nightly if you are so inclined) we can use rustc_on_unimplemented for traits, but it can get unwieldy. I wasn't so much designed as it was grown in an adhoc depending on the needs of the compiler itself, so I wouldn't expect a potentially stabilized attribute to look like it, but I would love it if the functionality were provided in some way.
Having some support for annotating state machines would also be lovely so when you call file.read() you get something like "file was consumed when it was closed by calling File::close", or something.
related, I would also love to use this on negative trait impls. I'd use it to attach a message for why &str and String don't impl Error
I'd also want to use this on Box<dyn Error> not implementing Error, but in this case it's harder because we don't want to make the API commitment to never implement it via a negative impl, the issue is currently insufficient support for specialization, though it might be hard to compress this explanation into a compiler error message. I'd probably prefer to use an --explain EXXXX for this case.
I don't think it needs an RFC at this point. The lang team is already actively working on this problem
From their 2022 roadmap draft
Theme: Help users help each other
The vision:
Library authors (and consumers) have tools to manage portability.
Library authors have tools to manage their development lifecycle.
Library authors can tailor the developer experience.
We achieve this by empowering library authors with new language capabilities, including those previously reserved for the compiler and standard library, such as lints, diagnostics, and stability attributes.
Libraries are key part of how Rust empowers its users, but developing and maintaining a Rust library should be easier. The standard library and compiler have access to a number of unique capabilities, ranging from diagnostics integration to the stable/nightly development cycle, that other Rust libraries cannot take advantage of. For Rust 2024, we want to empower library authors with new capabilities that make it easier to author and maintain Rust libraries.
IMO you should go straight to the lang zulip and open a topic to express your interest in participating with their planned effort