Allow negation of `if let`
Nobody has claimed this yet.
- Dominant language
- Markdown
- Stars
- 6.6k
- Forks
- 1.7k
- Avg merge
- 16h 14m
- Merged PRs (30d)
- 1
Description
The RFC for if let was accepted with the rationale that it lowers the boilerplate and improves ergonomics over the equivalent match statement in certain cases, and I wholeheartedly agree.
However, some cases still remain exceedingly awkward; an example of which is attempting to match the "class" of a record enum variant, e.g. given the following enum:
enum Foo {
Bar(u32),
Baz(u32),
Qux
}
and an instance foo: Foo, with behavior predicated on foo not being Bar and a goal of minimizing nesting/brace creep (e.g. for purposes of an early return), the only choice is to type out something like this:
// If we are not explicitly using Bar, just return now
if let Foo::Bar(_) = self.integrity_policy {
} else {
return Ok(());
}
// flow resumes here
or the equally awkward empty match block:
// If we are not explicitly using Bar, just return now
match self.integrity_policy {
Foo::Bar(_) => return Ok(());
_ => {}
}
// flow resumes here
It would be great if this were allowed:
// If we are not explicitly using Bar, just return now
if !let Foo::Bar(_) = self.integrity_policy {
return Ok(());
}
// flow resumes here
or perhaps a variation on that with slightly less accurate mathematical connotation but far clearer in its intent (you can't miss the ! this time):
// If we are not explicitly using Bar, just return now
if let Foo::Bar(_) != self.integrity_policy {
return Ok(());
}
// flow resumes here
(although perhaps it is a better idea to tackle this from an entirely different perspective with the goal of greatly increasing overall ergonomics with some form of is operator, e.g. if self.integrity_policy is Foo::Bar ..., but that is certainly a much more contentious proposition.)
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files or tests; start by reading issue #2616 and its 88-comment discussion, including the existing if-let rationale and the proposed negation forms. Done requires a resolved language-design direction for negated if-let syntax rather than an isolated edit.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100