<div dir="ltr">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.<div><br></div><div>This is useful in general if you need to work “down the rabbit hole”, so you could write something like:</div><div><br></div><div><font face="monospace, monospace">alias size = anArray[idx].someProperty.size</font></div><div><font face="monospace, monospace">// Work with “size” as a shorthand, including mutations</font></div><div><br></div><div>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:</div><div><br></div><div><font face="monospace, monospace">if alias b = c.a as? B {</font></div><div><font face="monospace, monospace"> b.x = 12</font></div><div><font face="monospace, monospace">}</font></div><div><br></div><div>I think this sort of feature is far more versatile than type-narrowing, and it retains the clarity of type information in source code.</div><div><br></div><div>Nevin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 6, 2016 at 10:52 PM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Nov 3, 2016, at 10:04 AM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 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.<br>
> 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.<br>
<br>
</span>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:<br>
<br>
… = foo is B ? foo.bMethod() : …<br>
<br>
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.<br>
<br>
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.<br>
<br>
-Chris<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div>