Conversation
|
Hi relnotes-interest-group, this PR adds a release blog post. Could you review cc @alex-semenyuk @jieyouxu @joshtriplett @lcnr @traviscross |
|
|
||
| We are generally interested in use cases that require custom target | ||
| specifications. TODO: Do we want a link to an issue where people can comment | ||
| with a use case? |
There was a problem hiding this comment.
@davidtwco do you want to link to something here? I think you've been driving collection of use cases to help answer my question here (davidtwco/rfcs#5 (comment))
Happy to file an issue on rust-lang/rust and point to it or whatever would make sense to you. Or we can drop this note entirely. Also open to opinions on restructuring the text (e.g., mentioning build-std).
| Note that the compiler will not currently consider the patterns matched in `if | ||
| let` guards as part of the exhaustiveness evaluation of the overall match, just | ||
| like `if` guards. |
There was a problem hiding this comment.
I don't know if this is worth calling out explicitly. I was actually half-expecting that this does participate in exhaustiveness analysis (it seems like we could make it do that, for the case where the RHS of the if let is a value from the match's expression).
I'm guessing our mental model is that these are 'just' guards though in which case the implemented behavior makes sense. If so, maybe we should strike 'currently' from this text.
Co-authored-by: Jake Goulding <shepmaster@mac.com>
4 participants
@rustbot ping relnotes-interest-group
cc @rust-lang/release
Rendered