Cleanup hack to expect scrutinee: bool
in if-to-match desugaring in match-expr typeck
#60707
Labels
C-cleanup
Category: PRs that clean code up or issues documenting cleanup.
F-let_chains
`#![feature(let_chains)]`
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
In #59288 a hack is introduced in
rustc_typeck::check::_match::check_match
that checks, viaMatchSource::IfDesugar
, whether anif
-expression was desugared tomatch
and if so, it requires that the scrutinee be typed atbool
.We might want to remove this hack in favor of a more principled solution, with options:
Fix type ascription such that it admits coercions and then use
ExprKind::Type(...)
to set the expectation that the type be coercible tobool
. This will require adjustments to diagnostics logic to reduce clutter.Use a cast
$scrutinee as bool
and useExprKind::Cast(...)
to set the expectation that the type be coercible tobool
. Same applies wrt. diagnostics.Add a flag in the type ascription HIR that enables the "coercion" behavior we want. This is still a hack but potentially less of a hack.
Remove the hack entirely and permit
if &true { ... }
to type check.This is a semantic change to the language but perhaps a desirable one. I (@Centril) believe it would facilitate usability since there are cases where you call a function and end up with
&bool
, e.g. indexing a slice ofbool
s. Right now you would have to deref the returned&bool
to make it work. I also think it is a semantic simplification of the language sinceif
becomes more of a pure in-language desugaring than before. cc @rust-lang/lang about this idea of applying default-match-bindings toif
conditions.For more context, see #59288 (comment) and #59288 (review).
The text was updated successfully, but these errors were encountered: