FWIW, we have specifically considered something like this proposal in the past. You didn’t mention it, but the ?: operator is a specific example that frequently comes up. People often expect to be able to do something like:
… = foo is B ? foo.bMethod() : …
which is the same sort of flow sensitive type refinement as you’re proposing here. This topic also came up in the design discussion around #available (which shipped in Swift 2, but was discussed much earlier), because unavailable decls could be available as optionals when not specifically checked for.
This is just MHO, but while I have been in favor of this in the (distant) past, I became convinced that this would be a bad idea when it comes to code maintenance over the long term. With our current (intentional shadowing based) design, you can always jump to the definition of a value to see where it was defined, and definitions always specify a type. Introducing flow senstitive type refinement breaks this model because the type of a decl depends not just on its declaration, but on a potentially arbitrary number of imperative checks that occur between the declaration and the use. This can make it much more difficult to understand code.
-Chris
···
On Nov 3, 2016, at 10:04 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:
To avoid hijacking the guard let x = x thread entirely I've decided to try to write up a proposal on type narrowing in Swift.
Please give your feedback on the functionality proposed, as well as the clarity of the proposal/examples themselves; I've tried to keep it straightforward, but I do tend towards being overly verbose, I've always tried to have the examples build upon one another to show how it all stacks up.