<div dir="ltr"><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important">Haravikk,</p>
<p style="margin:0px 0px 1.2em!important">I think you missed ilya’s point with the owner/pet example:</p>
<pre style="font-size:1em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code class="hljs language-swift" style="font-size:1em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline;white-space:pre;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important;display:block;overflow-x:auto;padding:0.5em;color:rgb(51,51,51);background:rgb(248,248,248) none repeat scroll 0% 0%"><span class="hljs-comment" style="color:rgb(153,153,136);font-style:italic">// This is inside the Owner class...</span>
<span class="hljs-func"><span class="hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">func</span> <span class="hljs-title" style="color:rgb(153,0,0);font-weight:bold">freeMyPetIfIHaveOne</span> </span>{
<span class="hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">if</span> pet != <span class="hljs-built_in" style="color:rgb(0,134,179)">nil</span> {
pet.setFree() <span class="hljs-comment" style="color:rgb(153,153,136);font-style:italic">// this sets pet = nil</span>
<span class="hljs-comment" style="color:rgb(153,153,136);font-style:italic">// self.pet is now nil - not due to concurrency, it was set to nil on this thread in the function above.</span>
<span class="hljs-comment" style="color:rgb(153,153,136);font-style:italic">// However, the compiler considers it a non-optional at this point</span>
pet.doStuff() <span class="hljs-comment" style="color:rgb(153,153,136);font-style:italic">// Compiler allows, bad things happen!</span>
}
}
</code></pre>
<p style="margin:0px 0px 1.2em!important">As Dennis mentioned, narrowing only works for immutable values, and since optionals are always mutable it defeats the whole justification for it. I like the concept, but maybe it should be for immutables only?</p>
<div title="MDH:PGRpdj48ZGl2PkhhcmF2aWtrLDxicj48YnI+PC9kaXY+PGRpdj48L2Rpdj5JIHRoaW5rIHlvdSBt
aXNzZWQgaWx5YSdzIHBvaW50IHdpdGggdGhlIG93bmVyL3BldCBleGFtcGxlOjxicj48YnI+PC9k
aXY+PGRpdj5gYGBzd2lmdDxicj48L2Rpdj48ZGl2Pi8vIFRoaXMgaXMgaW5zaWRlIHRoZSBPd25l
ciBjbGFzcy4uLjxicj48L2Rpdj48ZGl2PjxkaXYgY2xhc3M9ImdtYWlsX21zZyI+ZnVuYyBmcmVl
TXlQZXRJZklIYXZlT25lIHs8L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9tc2ciPiZuYnNwOyBpZiBw
ZXQgIT0gbmlsIHs8L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9tc2ciPiZuYnNwOyAmbmJzcDsgcGV0
LnNldEZyZWUoKSAvLyB0aGlzIHNldHMgcGV0ID0gbmlsPGJyPjwvZGl2PjxkaXYgY2xhc3M9Imdt
YWlsX21zZyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC8vIHNlbGYucGV0IGlzIG5vdyBuaWwgLSBub3Qg
ZHVlIHRvIGNvbmN1cnJlbmN5LCBpdCB3YXMgc2V0IHRvIG5pbCBvbiB0aGlzIHRocmVhZCBpbiB0
aGUgZnVuY3Rpb24gYWJvdmUuPGJyPjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX21zZyI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7IC8vIEhvd2V2ZXIsIHRoZSBjb21waWxlciBjb25zaWRlcnMgaXQgYSBub24t
b3B0aW9uYWwgYXQgdGhpcyBwb2ludDxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9tc2ciPiZu
YnNwOyZuYnNwOyZuYnNwOyBwZXQuZG9TdHVmZigpIC8vIENvbXBpbGVyIGFsbG93cywgYmFkIHRo
aW5ncyBoYXBwZW4hPGJyPjwvZGl2PiZuYnNwOyB9PGRpdiBjbGFzcz0iZ21haWxfbXNnIj59PGJy
PmBgYDxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9tc2ciPkFzIERlbm5pcyBtZW50aW9uZWQs
IG5hcnJvd2luZyBvbmx5IHdvcmtzIGZvciBpbW11dGFibGUgdmFsdWVzLCBhbmQgc2luY2Ugb3B0
aW9uYWxzIGFyZSBhbHdheXMgbXV0YWJsZSBpdCBkZWZlYXRzIHRoZSB3aG9sZSBqdXN0aWZpY2F0
aW9uIGZvciBpdC4gSSBsaWtlIHRoZSBjb25jZXB0LCBidXQgbWF5YmUgaXQgc2hvdWxkIGJlIGZv
ciBpbW11dGFibGVzIG9ubHk/PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfbXNnIj48YnI+PC9kaXY+
PC9kaXY+" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0"></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 10 Nov 2016 at 11:27 Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 10 Nov 2016, at 10:32, Dennis Lysenko <<a href="mailto:dennis.s.lysenko@gmail.com" class="gmail_msg" target="_blank">dennis.s.lysenko@gmail.com</a>> wrote:</div><div class="gmail_msg"><p dir="ltr" class="gmail_msg">So a lot of concerns here especially ilya's are ones that wouldn't be brought up if people looked at existing successful implementations like Kotlin where they are clearly solved. (fyi, answer is only narrowing with immutable values.) </p><p dir="ltr" class="gmail_msg">Personally I think type narrowing with explicit opt-in has no value. All or nothing, the whole meat of the proposal is in it being implicit. </p></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Right you are, I think an explicit keyword is only required for optionals; stripping them out into their own proposal simplifies things considerably. I've tweaked the type-narrowing specific proposal to return implicit narrowing (or explicit via the is keyword and assignment, depending upon how you want to look at it).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I do think there is still value in handling reference types as well, but I'm proposing that this is done with a new force is! keyword which forces the narrowing (but causes a runtime concurrent modification error if the type no longer matches what the type-checker expects), as well as a new @concurrency(safe) attribute that can be used to indicate variables that posses a safe reference to an instance, e.g- for types that use a storage class for copy-on-write functionality, or where the value is local to a method etc. (though this isn't enforced).</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><p dir="ltr" class="gmail_msg">if it makes compilation times even slower I'm probably against it - xcode in general has been driving me up a wall lately with a matter of minutes for compiling and signing our (not huge) project, so any compiler speed improvements take on increased precedence for me.</p></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">While I agree that the current performance can leave a lot to be desired, I don't think that this should actually slow it down by any meaningful amount; most variables won't narrow so will just be a single type as normal, and with optionals removed from the narrowing process the type-checker should only ever need to compare against the narrowest type on the stack, i.e- the only time wider types are considered is when you assign a wider type to a narrowed variable, and that's just popping types off the stack to get the new current type.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">But yeah, if it were have a big impact on performance I'd recommend delaying it until major optimisation work has been done, but I don't see that it should make much of a difference, and it really shouldn't be any more of a burden than shadowing is today.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">
<div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg"></div></div></div></blockquote><blockquote type="cite" class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Nov 9, 2016, 13:52 Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So I'm trying to re-write the proposal with the use of a keyword for unwrapping in mind, to keep it simpler for myself I've done this as two separate proposals for the time being, one for simpler unwrapping of optionals, and one for type-narrowing of polymorphic types:<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-optional-unwrapping.md" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-optional-unwrapping.md</a><br class="gmail_msg">
<a href="https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-type-narrowing.md" rel="noreferrer" class="gmail_msg" target="_blank">https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-type-narrowing.md</a><br class="gmail_msg">
<br class="gmail_msg">
In addition to feedback on each proposal, I'm interested to know whether people think it is better to keep these separate? They're still very similar features, but the differences make it pretty awkward to keep them in one big proposal.<br class="gmail_msg">
<br class="gmail_msg">
I've also given up on integrating enums generically into it; as I don't think it's possible to do it in a similar enough way, and some extension to pattern matching would probably be better anyway.<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></blockquote></div></div></blockquote></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div>
</div></blockquote></div><br class="gmail_msg"></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>