Our great sponsors
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Hello Rustaceans, the same lab that has brought you The Rust Book Experiment, Aquascope, and Flowistry is starting a new endeavor. We want to understand when Rust's trait system makes it hard for you to understand or debug a Rust program.
Hello Rustaceans, the same lab that has brought you The Rust Book Experiment, Aquascope, and Flowistry is starting a new endeavor. We want to understand when Rust's trait system makes it hard for you to understand or debug a Rust program.
That's a topic where already some work exists. You might want to checkout my collection of bad error messages from such trait heavy crates for example. It's important to notice that most of these errors look complicated, but mostly have a quite simple cause. In some of these cases it's even possible to reword these error messages by removing most of the complicated looking type stuff to something much simpler which then is easier to understand.
Rustc provides an internal #[rustc_on_implemented] attribute for annotating traits to provide custom error messages for such cases. For example this PR demonstrated that it's possible to use such messages to improve the generated compiler error messages. As that existing attribute is a compiler internal attribute it cannot be used on stable rust.
I've proposed an RFC to have such an attribute on stable rust. This should hopefully help to improve some of the error messages, although this might not solve all the problems there, due limitations on complex filtering there.