NLinker

Rust 1.0 mistakes

Jul 18th, 2018
371
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!

Rust 1.0 mistakes

Aaron’s List

NB: many of these are not “objectively” mistakes, but rather aturon’s opinion

  • Bare Trait syntax (rather than dyn Trait)
  • The Error trait (busted downcasting)
  • The inconsistent privacy defaults with different data types
  • The struct creation syntax (using :)
  • Macro syntax future-proofing (which… isn’t)
  • io::Error not working in core
  • The {:?} syntax which is so annoying to type
  • Arc<F> and Rc<F> not being Fn(A) -> B when F is
  • Everything here: https://github.com/rust-lang/rust/issues?q=is%3Aissue+label%3Arust-2-breakage-wishlist+is%3Aclosed
  • Including channels in std
  • Exposing String repr such that the capacity hack for literals won’t work
  • PartialOrd

Centril’s added opinion (implying agreement with the above set ^^):

  • struct and enum should have just been data, i.e: one keyword
  • type variables should have started with lowercase and concrete types with uppercase, and would permit fn id(x: t) -> t — tho this would lead to some possibly problems wrt. extern that you could overcome.
  • the “head” type parameter of a trait is implicit

Niko’s thoughts for things beyond that set ( not implying agreement with all of them =) ):

  • permitting “lifetime-sensitive dispatch” on traits
    • put another way: #[``specialization_predicate``] should have been the default
    • unlike most other things, can’t readily fix with an edition
  • adding AsRef impls breaks type inference =)
  • moving methods to inherent impls breaks type inference
  • edition-sensitive method resolution
  • &uniq — that prohibits mutation but guarantees uniqueness — might have been useful for things like Pin; I wonder if there is a way to rephrase &mut T in terms of &uniq Mut<T>, where Mut is analogous to Cell but requires an &uniq and not an &T.

Josh’s additions:

  • fmt::Write and io::Write having the same name.

Simon:

  • Range types implementing Iterator themselves, rather than just IntoIterator.

Yehuda’s additions:

  • mod syntax
  • such fine-grained privacy by default (vs. a more crate-centric default)
  • String literals are not String
  • No cross-crate coherence solution (some way to scope coherence to a bigger unit than “crate” that you still own)
  • Controversial: impl<T> Foo<T> {}
    • I think in-band declaration should be allowed, just as it’s now allowed for lifetimes
Add Comment
Please, Sign In to add comment