[swift-evolution] [Proposal] Type Narrowing

[Chris Lattner]

> On Nov 3, 2016, at 10:04 AM, Haravikk via swift-evolution <swift-evolution at 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.

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