<p dir="ltr">So a lot of concerns here especially ilya&#39;s are ones that wouldn&#39;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">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>
<p dir="ltr">I see too many people predisposed to considering this as if it&#39;s &quot;compiler magic&quot; to the point where I don&#39;t feel the cost of arguing is worth what it would bring to the language. Sure, it&#39;s a nice piece of syntax sugar but it&#39;s not going to revolutionise it, and if it makes compilation times even slower I&#39;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>
<p dir="ltr">Just my 2c. </p>
<p dir="ltr">Dennis </p>
<br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 9, 2016, 13:52 Haravikk via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So I&#39;m trying to re-write the proposal with the use of a keyword for unwrapping in mind, to keep it simpler for myself I&#39;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&#39;m interested to know whether people think it is better to keep these separate? They&#39;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&#39;ve also given up on integrating enums generically into it; as I don&#39;t think it&#39;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>