[swift-evolution] [Proposal] Type Narrowing

[Nevin Brackett-Rozinsky]

The more I think about it, the more I realize what I actually want is an
“alias” or “view” or “lens” that will let me give a new name to an existing
entity, without copying or moving it.

This is useful in general if you need to work “down the rabbit hole”, so
you could write something like:

alias size = anArray[idx].someProperty.size
// Work with “size” as a shorthand, including mutations

In the situation from my previous example, where we only want to take
action when the nested property is a certain type, it might look like:

if alias b = c.a as? B {
    b.x = 12
}

I think this sort of feature is far more versatile than type-narrowing, and
it retains the clarity of type information in source code.

Nevin


On Sun, Nov 6, 2016 at 10:52 PM, Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161107/fec07a9e/attachment.html>