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 thandyn 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 incore
- The
{:?}
syntax which is so annoying to type Arc<F>
andRc<F>
not beingFn(A) -> B
whenF
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
andenum
should have just beendata
, 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
- put another way:
- 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 likePin
; I wonder if there is a way to rephrase&mut T
in terms of&uniq Mut<T>
, whereMut
is analogous toCell
but requires an&uniq
and not an&T
.
Josh’s additions:
fmt::Write
andio::Write
having the same name.
Simon:
- Range types implementing
Iterator
themselves, rather than justIntoIterator
.
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