Language removals in editions

language design
3

I think there should always be a discussion for each RFC (that extends the language) on how to add the feature as conservatively as possible by reusing whatever constructs are already in the language.

There’s a balance to strike, of course. A while back, for example, I suggested that we don’t really need try-blocks as a language construct because the same mechanism can be implemented by reusing block labels – a much smaller and simpler change to the language. Now, the ergonomics would probably suffer comparatively with that design, but there was a constructive discussion.

I’d like to see more focused discussions on the aspect of how to grow the language minimally. Perhaps that should be a mandatory point in the RFC process.

  • reuse existing constructs as much as possible
  • avoid new syntax if possible
  • describe the proposed change in possible levels of adoption
  • describe the proposed change’s overlap, orthogonality and interactions with other constructs
  • prefer const fn or macro to keyword
  • prefer crates.io to std (this I think we do well, btw)
  • prefer impl Trait to standardising on concrete types
8 Likes