Skip to content

A "Removed Features FAQ" for historical reference #4632

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bstrie opened this issue Jan 25, 2013 · 4 comments
Closed

A "Removed Features FAQ" for historical reference #4632

bstrie opened this issue Jan 25, 2013 · 4 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@bstrie
Copy link
Contributor

bstrie commented Jan 25, 2013

Inspired by a question on Reddit (http://www.reddit.com/r/rust/comments/178t57/intimidation_factor_vs_target_audience/c83br4f). Basically all it needs to contain is a list of removed features, with a reason for the removal of each. In addition to being fascinating, it would be a good resource for other would-be language designers. Here's what I came up with off the top of my head (pasted from the Reddit thread):

  • Typestate (because nobody used it)
  • Structural records (in favor of nominal records (structs), but I'm not sure of the exact reason)
  • Argument modes (frustrating to use, impossible to learn, horrifying to look at; replaced with borrowed pointers)
  • Classes (because the day after they finished implementing them they realized you could get the same effect from combining impls and structs)
  • Ternary operator (because if is already an expression)
  • Resources (in favor of drop {} blocks within struct definitions, which were then themselves removed in favor of the Drop trait)
  • Explicit move, first via the <- operator and then via the move keyword (now owned types always move unless you explicitly copy them (and even the copy keyword will soon be gone in favor of a compiler-generated .copy() method)
  • Long-style closure expressions (in favor of the shorter || {} syntax)
  • Old-style operator overloading (in favor of the overloading traits in core::ops)
  • comm-style primitives (replaced with pipe-style primitives, which are way faster, more basic, and can be used to implement comm-style if you really want it)
  • Module-wide export declarations (now you denote visibility on the item itself)
  • Mandatory integer-literal and float-literal type suffixes (they were a pain to use, and are now inferred if you leave them off)
  • do-while loops (rarely used, trivial to emulate)
  • fn foo() unsafe { (which was different from unsafe fn() foo, and can be approximated by fn foo() { unsafe {)
  • Guaranteed tail recursion via the be keyword (requires changing the calling convention, which is a performance cost that they just can't afford)
  • The bind keyword (rarely used, syntax was unintuitive, and not difficult to emulate via closures)
  • note statements (not actually sure why they were removed, I'm not sure if they were ever even implemented)
  • (WIP) The static keyword (any method definition without a self argument is static)
  • (WIP) The log, fail, and assert keywords (these can all be done as macros).
  • (WIP) The concepts of both const and pure (likely obviated by the new INHTWAMA work)
  • (Possibly) field-level mutability (in favor of object-wide "inherited" mutability)
@z0w0
Copy link
Contributor

z0w0 commented Mar 14, 2013

I think it would be better to integrate this with a history of Rust page. That would be even more fascinating. Certain entries could have an optional explanation that can be folded out explaining why it happened, e.g. why $x was removed.

@asb
Copy link

asb commented Mar 14, 2013

I like @z0w0's idea a lot. It could include links to mailing list discussion, relevant blog posts and the like. Of course it requires work to set up, but it could be a pretty useful resource in the future for reminding people why design decision were made.

@alexcrichton
Copy link
Member

This seems very related to #2172, and I'll nominate for the same milestone (complete)

@graydon
Copy link
Contributor

graydon commented May 2, 2013

Yeah, subsection of #2172

@graydon graydon closed this as completed May 2, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

5 participants