Open bionicles opened 10 months ago
I think if these kind of compile failures were easier to code and easier to read, then it would be a major improvement for the Rust 2024 edition release, because it would enable us to shift a ton of runtime errors into compile time errors,
@bionicles I am strongly in favor of more to-the-point error messages in roughly the way you mentioned, but nothing you described requires a new edition to be released.
Yes, you're right @workingjubilee
Code
https://github.com/bionicles/broadcastable is ready to roll.
here's the one-liner to get it going
here are the complete contents of that crate
Cargo.toml:
src/lib.rs:
tests/ui/compatibility_fail.rs
Current output
Desired output
Rationale and extra context
Motivation
Type Level Rust is crucial to ensure correct programs before runtime crashes. While it is possible in many cases to achieve compile-time errors, they often involve HLists (heterogeneous lists) to make a "Russian Doll" nesting of types to recursively represent complex abstractions as types.
Unfortunately,
rustc
tends to verbosely log the recursive nested type (not readable concrete type) instead of the high-level abstraction (readable desired alias) ... so for example we might as humans expect to see "U3" for a type level unsigned number three, but instead we seeUInt<UInt<UTerm, B1>, B1>>
you can imagine a more realistic application of HList and TypeNum:
Cons<UInt<UInt<UTerm, B1>, B1>>, Cons<UInt<UInt<UTerm, B1>, B1>>, Cons<UInt<UInt<UTerm, B1>, B1>>, Nil>>>
makes something which could be a real strength of rust (compile time correctness checking) into an unreadable mess.I think if these kind of compile failures were easier to code and easier to read, then it would be a major improvement for the Rust 2024 edition release, because it would enable us to shift a ton of runtime errors into compile time errors, thereby amortizing (do work once, reuse result many times) computation to dramatically improve performance. The big blockers are, it's hard to implement these sorts of things, and it's hard to read the error messages when you do implement them.
Proposed Improvements:
Improved Error Message Readability: Enhance the compiler's ability to present type-level errors in a more digestible and human-readable format. This could involve better summarization of the core issue, reducing the verbosity of nested type information, or providing contextual hints.
Customizable Compile-Time Errors: Develop a mechanism that allows library authors to provide custom compile-time error messages under specific type-level conditions. This feature would enable developers to create more informative and user-friendly error messages, tailored to the specific constraints and requirements of their libraries.
Enhanced Type-Level Debugging Tools: Introduce tools or compiler features that aid in debugging complex type-level code, possibly integrating with existing IDEs or Rust toolchains.
Other cases
No response
Anything else?
No response