<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 9 Nov 2016, at 12:19, Rien <<a href="mailto:Rien@balancingrock.nl" class="">Rien@balancingrock.nl</a>> wrote:</div><div class=""><blockquote type="cite" class="">On 9 Nov 2016, at 06:51, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote></blockquote><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><blockquote type="cite" class=""></blockquote></blockquote></blockquote></div></blockquote><div class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On 3 Nov 2016, at 20:23, Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">This looks like a lot of complexity for very little gain.<br class=""><br class="">Aside from any implementation concerns, this proposal substantially increases the cognitive load on developers. To figure out what a piece of code means, someone reading it will have to mentally keep track of a “type stack” for every variable. That is the opposite of “clarity at the point of use”.<br class=""></blockquote></blockquote></blockquote></div><blockquote type="cite" class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><br class="">Very well said. I think this is perhaps the number one complaint I have about the proposal.<br class=""></blockquote><br class="">Did you see my response to this? There should be no particular cognitive load increase; think of the feature like type inference, the idea here is that the type-checker is gaining the same knowledge that you already have, i.e- you know something isn't nil, so the type-checker should too.<br class=""></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Locally in short routines yes.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">But in larger modules and non-local this does not apply.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>I'm not sure what you mean; type-narrowing doesn't occur across scopes, ultimately you will always have some starting type where the variable was declared as a property, function argument or local variable, and it is narrow only where it is used, and the narrowing only occurs within that scope for as long as it is relevant.</div><div><br class=""></div><div>In other words, the narrowing is always local. If you know your method takes an optional string for example then you know that that variable is still an optional string throughout that method, type-narrowing just helps to guarantee that it is nil or non-nil where you expect it to be.</div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Imo it should always be possible to look at a type declaration and -from that- derive all necessary knowledge about the type.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>As I say, narrowing never changes the type; if you have a variable with a declared type of Foo, that is narrowed to Bar, then it is because Bar extends Foo and thus is compatible with it, giving you access to any additional methods of Bar without interfering with what you know of Foo.</div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Besides when using a narrowed type as a parameter for an optional it must be automatically be widened again? hence you would mentally keep track of the status of that variable.</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><br class=""><div class="">I'm not sure I follow this question; do you mean something like this:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>func someMethod(foo:Foo?) {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var bar:Foo? = nil // bar is Optional<Foo>.none</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if (foo != nil) { // foo is Optional<Foo>.some</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>bar = foo // both foo and bar are Optional<Foo>.some</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// both foo and bar are Optional<Foo> (alternative branch places no mutual guarantee on type)</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if bar != nil { // bar is Optional<Foo>.some</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>bar.someMutatingMethod()</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}</font></div><div class=""><br class=""></div><div class="">But these are all things that the developer knows; bar can't be non-nil until a value for it is set, foo is definitely non-nil within the block etc. The only difference here is that instead of the developer having to use ! unnecessarily (or risk making a mistake) they can just use their knowledge of what it is to interact directly, as the type-checker will now also know the same thing.</div><div class=""><br class=""></div><div class="">However, with the Optional<T> to T method shadowing issue it seems we probably will need to require a keyword, or at the very least restrict automatic narrowing to polymorphism. For optionals the code will have to look something like this:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func someMethod(foo:Foo?) {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var bar:Foo? = nil</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if unwrap foo {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>bar = foo</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if unwrap bar {</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>bar.someMutatingMethod()</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><font face="Monaco" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</font></div><div class=""><br class=""></div><div class="">The difference here is that unlike shadowing (if let foo = foo), if foo were mutable then it could still be mutated directly, no need to do it with force unwrapping. Of course in these simple examples you could just use the question mark operator instead, but pretend we're doing more than one thing per conditional 😉</div></body></html>