In #59288 a hack is introduced in rustc_typeck::check::_match::check_match that checks, via MatchSource::IfDesugar, whether an if-expression was desugared to match and if so, it requires that the scrutinee be typed at bool.
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 to bool. This will require adjustments to diagnostics logic to reduce clutter.
-
Use a cast $scrutinee as bool and use ExprKind::Cast(...) to set the expectation that the type be coercible to bool. 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 of bools. 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 since if becomes more of a pure in-language desugaring than before. cc @rust-lang/lang about this idea of applying default-match-bindings to if conditions.
For more context, see #59288 (comment) and #59288 (review).
In #59288 a hack is introduced in
rustc_typeck::check::_match::check_matchthat checks, viaMatchSource::IfDesugar, whether anif-expression was desugared tomatchand 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 booland 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 ofbools. Right now you would have to deref the returned&boolto make it work. I also think it is a semantic simplification of the language sinceifbecomes more of a pure in-language desugaring than before. cc @rust-lang/lang about this idea of applying default-match-bindings toifconditions.For more context, see #59288 (comment) and #59288 (review).