<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 8 Nov 2016, at 12:22, ilya <<a href="mailto:ilya.nikokoshev@gmail.com" class="">ilya.nikokoshev@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">(1) You can define different methods with the same name on T and Optional<T> (description is such an example). Then what does this do?<div class=""><br class=""></div><div class="">// someMethod is defined both for T and T?</div><div class="">// var foo: T?</div><div class="">if foo != nil {</div><div class=""> foo.someMethod()</div><div class="">}</div><div class=""><br class=""></div><div class="">I say there is a clear expectation that foo.someMethod() should call the method of T?, even inside the if block, since this is how the dot works. However, according to the proposal it will call another method (or become an error?).<br class=""></div><div class=""><div class=""><br class=""></div></div></div><div class="">I think the languages that use optional narrowing are the ones where T? is not a separate type, so that it cannot have its own methods.</div></div></div></blockquote><div><br class=""></div><div>Hmm, that is definitely a wrinkle in the plan; it's very much an edge case (someone defining something on optionals that they probably shouldn't) but not an easy one to resolve. I suppose I'll have to amend the proposal to suggest type widening in that case, such that you would need to use ! or ? as normal to specify the unwrapped value. The tricky part is that it means the value would have to be widened from the start, otherwise you'd be accessing the value in two different ways in the same block of code, which would mean that narrowing would need to be blocked if there's an incompatible statement further down… ugh, perhaps a keyword will be necessary then? I was really hoping to avoid having to add one though.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">(2) Should this work?</div><div class=""><br class=""></div><div class="">// compilcatedStuff is a method of T</div><div class=""><div class="">// class A { var foo: T? }</div><div class=""><br class=""></div><div class="">if foo != nil {</div><div class=""> foo.compilcatedStuff()</div><div class=""> foo.compilcatedStuff()</div><div class=""><div class=""> foo.compilcatedStuff()</div><div class="">}<br class=""></div></div><div class=""><br class=""></div></div><div class="">Suppose the compiler doesn't have enough information about compilcatedStuff to know what happens inside. Then it's possible that foo.compilcatedStuff will actually change foo (for example, foo could be a relationship and compilcatedStuff may be deleting the relationship). So, what is the suggestion for this example? Perhaps</div><div class=""><br class=""></div><div class=""><div class="">if foo != nil {</div><div class=""> foo.compilcatedStuff()</div><div class=""> foo?.compilcatedStuff()</div><div class=""> foo?.compilcatedStuff()</div><div class="">}</div><div class=""><br class=""></div></div><div class="">or some other choice?</div></div></blockquote></div><br class=""><div class="">What do you imagine being inside .complicatedStuff()? It shouldn't be possible for it to change foo to nil, as even if .complicatedStuff() reassigned this, it would be doing so as type T.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""></div><blockquote type="cite" class=""></blockquote></blockquote><blockquote type="cite" class=""><div class="">On 9 Nov 2016, at 06:51, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:</div></blockquote><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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=""></blockquote></blockquote><div class=""><blockquote type="cite" class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"></blockquote><div class=""><blockquote type="cite" class=""><span class="" style="font-size: 14px; float: none; display: inline !important;">This looks like a lot of complexity for very little gain.</span></blockquote><div class="" style="font-size: 14px;"><blockquote type="cite" class=""><br class=""></blockquote></div><div class="" style="font-size: 14px;"><blockquote type="cite" 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”.</blockquote></div></div></blockquote></div><blockquote type="cite" class=""><br class=""></blockquote><div class=""><blockquote type="cite" class="">Very well said. I think this is perhaps the number one complaint I have about the proposal.</blockquote></div><div class=""><br class=""></div><div 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.</div></div></div></div></body></html>