Read on Twitter
I watched the 2021 edition design meeting today and thought I might do a "short" summary of the points I found interesting
Feel free to ask for elaboration on any of the sections below, I'm trying to keep it brief (and failing a little
)
So yea, THREAD
Feel free to ask for elaboration on any of the sections below, I'm trying to keep it brief (and failing a little
)So yea, THREAD
Changes prepping for the edition should all start materializing by October it seems, based on comments throughout the meeting
# Implied bounds
apparently there are API compatibility hazards here, where if implied bounds are depended upon by an external crate removing a bound from the struct would be a breaking change.
apparently there are API compatibility hazards here, where if implied bounds are depended upon by an external crate removing a bound from the struct would be a breaking change.
This can be mitigated a few ways, either restrict implied bounds to only the crate, make implied bounds be publicly exportable, or maybe some fancy stuff based on usage that i didn't totally understand.
@josh_triplett can probably expand on this last point better than I can
alternatively, here's the link to the specific time
alternatively, here's the link to the specific time
# Specialization
Not much backwards incompatibility so not very relevant to edition planning.
There's talk of making it eventually opt-out by default, but it doesn't seem likely that this would happen short term, so specializable impls must be marked `default` initially.
Not much backwards incompatibility so not very relevant to edition planning.
There's talk of making it eventually opt-out by default, but it doesn't seem likely that this would happen short term, so specializable impls must be marked `default` initially.
Also they may initially stabilize the `min_specialization` subset being used in the compiler right now which I think only allows specializing for concrete types, not for things like `T where T: Trait`.
# if let or exit function
They talked about implementing an inverse fallible binding for making a binding or exiting early that might require a small backwards incompatible change that doesn't affect any known code.
They talked about implementing an inverse fallible binding for making a binding or exiting early that might require a small backwards incompatible change that doesn't affect any known code.
The main syntax proposal seems to be
let Some(x) = y else {
return Err(BrokenThingsAlert);
}
println!("{}", x);
This also ties into or patterns, they might be looking for ppl motivated to work on this
let Some(x) = y else {
return Err(BrokenThingsAlert);
}
println!("{}", x);
This also ties into or patterns, they might be looking for ppl motivated to work on this
# Unsafe in Unsafe Function
they're working on making the bodies of unsafe fns safe by default, but due to the size of the change they're considering breaking this up across multiple editions I think.
they're working on making the bodies of unsafe fns safe by default, but due to the size of the change they're considering breaking this up across multiple editions I think.
They're definitely planning on handling this with `rustfix` but its unclear how well they can do this, so its unclear but it might be that in 2021 its only a warning if you use an unsafe expr in an unsafe fn without an unsafe block.
# Function Equals Expression
THEY MENTIONED IT WOOO, for like 2 seconds, but that's good news in my eyes!!
fn equals expr is when you can use any expression as the body of a function, for example:
fn foo(&self) -> Result<i32, Error> = try {
// that good shit goes here...
}
THEY MENTIONED IT WOOO, for like 2 seconds, but that's good news in my eyes!!
fn equals expr is when you can use any expression as the body of a function, for example:
fn foo(&self) -> Result<i32, Error> = try {
// that good shit goes here...
}
# Asm Keyword vs Macro
apparently this is a thing but they didn't get into it.
apparently this is a thing but they didn't get into it.
# Early return with error
looking to reserve a keyword with this, YEET IS A STRONG CONTENDER AND GOT MENTIONED IN THE MEETING (as a joke)
reserving a keyword is dependent upon them resolving the bikeshed to pick one, which hasn't even started yet tho, soooo
looking to reserve a keyword with this, YEET IS A STRONG CONTENDER AND GOT MENTIONED IN THE MEETING (as a joke)
reserving a keyword is dependent upon them resolving the bikeshed to pick one, which hasn't even started yet tho, soooo
# Impl Trait
Seems to be progressing nicely, there are some discrepancies between the RFC and the implementation that need to be reviewed.
This will apparently help with async fns, tho not the ones with GATs, but niko seemed to think that will be done by 2021 as well maybeee ??
Seems to be progressing nicely, there are some discrepancies between the RFC and the implementation that need to be reviewed.
This will apparently help with async fns, tho not the ones with GATs, but niko seemed to think that will be done by 2021 as well maybeee ??
# implicit mod and crate visibility
I didn't follow this one closely, sorry
I didn't follow this one closely, sorry
# Type Ascription (and Named Arguments)
They're particularly worried about not conflicting with future named arguments syntax, so it seems like they might deprecate some syntax to allow named args to use `=` as a separator so type ascription can safely use `:`
They're particularly worried about not conflicting with future named arguments syntax, so it seems like they might deprecate some syntax to allow named args to use `=` as a separator so type ascription can safely use `:`
AND THAT'S IT
The above is a little out of order because I started this thread half way thru the video, sorry about that
But yea, I hope this helped, and if you're interested in watching the entire thing here's the link.
The above is a little out of order because I started this thread half way thru the video, sorry about that
But yea, I hope this helped, and if you're interested in watching the entire thing here's the link.
