> On Nov 3, 2016, at 10:04 AM, Haravikk via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
