ebingdom

I'm pretty confident Simon Peyton-Jones would never find it acceptable that adding a new type class instance changes the behavior of existing code, regardless of what convenience it brings. Yes, the dot operator is useful (as SPJ acknowledges in that talk), but convenience at the cost of sacrificing the ability to reason about code and how its meaning evolves is not worth it to the typical Haskeller. SPJ isn't talking about Rust specifically in that talk; he's only talking about the convenience of IDE integration and namespacing based on the receiver.

I think you have it reversed. `expr.expr` would need to become `(*expr).expr` if we didn't have auto-dereferencing.

I love Rust, but one thing that seems like a glaring design flaw is that adding a new trait implementation can change the behavior of existing code. This is very counterintuitive, because it seems like a purely additive change. In my opinion, the convenience of auto-dereferencing "as much as possible" to make method call syntax magically work through the indirection of references is not worth the lack of stability guarantees that it causes. This isn't a normal kind of breakage where the compiler points out what code you need to fix; this is a much worse kind of breakage where you might not even realize your code now behaves differently. In my opinion, the notion of "editions" is not an acceptable solution to this.

For a language that prioritizes safety, there are a surprising number of gotchas in Rust (another example is the large number of partial functions in the standard library).