[Roadmap 2017] Productivity: learning curve and expressiveness

Like many commenters here, I’m personally opposed to implicty and coersiony things. We can and probably will debate them endlessly, but I rather focus on other less controversial measures instead. There’s a decent amount of funny corner cases in the language that are confusing for experts. And while most beginners live in blissful ignorance of them, if they do run across them they’ll fare no better, Some examples would be:

  • Drop is very complex (and as I always point out, &mut seems wrong to me)
  • Closures in argument position get better inference.
  • Box needs lots of compiler magic
  • Secret &uniq borrow for closure bodies (though this worries me a lot less than when I first heard of it :))

I would not mine a moratorium on all but the most trivial new language features so we can better get a census on these odd corners. After that, I’d like to think about how we can remove these corner-cases. For example, my Stateful MIR proposal (A Stateful MIR for Rust) is as much of an attempt to reduce the number of features by subsuming them into fewer more powerful ones (or at least providing safe desugarings) as it is a drive for more expressiveness for expresiveness’s sake.

People talk about the Rube Goldberg machines that C++ (and to a lesser extent Scala) are, and I think that its important to realize that even when that’s explicitly not our attempt we can get there by mistake. I think a periodic enumerating and culling of oddities is a great and necessary housekeeping to keep it from happening.

12 Likes