I’ve written a decent deal on this topic before, both in a blog post pretending to be a rust2018 post and here on irlo.
I do like refinement typing / flow typing / smart casts in Kotlin, but in Kotlin it only happens for a) non-nullable from nullable and b) subtype from supertype.
But I honestly think that “guard let”/“refutable let” is the way to go for Rust, making a semantic version of let pat = match expr { pat => pat, _ => ! }.
The problem is that it requires introducing a new syntax to do something that is already very possible (using the “match” desugar). It’s a question of how much gain we get for the cost.
And I don’t know whether it’s really worth it. The match version is strictly more powerful, and the _ arm is already required to be appropriately typed, which includes diverging/breaking.
Where it starts becoming a clear win is when you are binding more than one thing in the refutable let. But how much does that actually happen, where you actually have a deep pattern and extract multiple values or bail?
I think it’s worth it to “canonize” the “guard” pattern with some dedicated syntax to encourage people to use that syntax instead of introducing rightward drift. But proving that to people and the several valid arguments against is no simple task.
Not to mention the bikeshed potential which tends to drown out meaningful talk a lot of the time 