<p dir="ltr">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">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's "compiler magic" to the point where I don't feel the cost of arguing is worth what it would bring to the language. Sure, it's a nice piece of syntax sugar but it's not going to revolutionise it, and 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>
<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 <<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">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>