I think I saw something about how FromStr predated TryFrom and FromIterator was because Iterator was a trait, so there was trouble defining eg loops in terms of where T: From<U>, U: Iterator? In any case it seems pretty reasonable to me that there's a simple go-to "default" conversion trait, I just wish the mutual implementation of From and Into was a bit less confusing (default only methods maybe?)
The ownership implications are terrifying. Automatically choosing between &self/&mut self/self based on "context" completely undermines Rust's careful ownership model. What happens when an implicit view() takes ownership unexpectedly?
We already have solutions:
For arguments - impl Into with #[momo]
For assignments - explicit .into() calls
For references - AsRef/Borrow These may be slightly more verbose but they're clear, predictable, and maintain Rust's philosophy
The comparison to Deref coercion is telling - Deref is already one of Rust's most controversial features because of how it breaks expectations. Doubling down on this with even more implicit behavior is the wrong direction
Did you mean to reply to someone else?
Is this for ergonomics, or does it enable additional expressiveness?
For Rust, robust type inference is quite important. It's already pretty fragile when you manually add .into() in multiple places. I imagine that implicit conversion/projection possible in many places would make type inference implementation even more difficult.
Swift struggles with exponential explosion of types caused by chained implicit conversions, and has to have a timeout for its type checker.
Deref is already problematic for Rust, since it's not guaranteed to be pure. This risk of running arbitrary user code on every access, and possibility of deref changing object's identity made it incompatible with patterns.
5 Likes