<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 Jan 4, 2018, at 3:50 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><div class="gmail_quote"><div dir="auto" class="">On Thu, Jan 4, 2018 at 18:39 Cheyo J. Jimenez <<a href="mailto:cheyo@masters3d.com" class="">cheyo@masters3d.com</a>> wrote:<br class=""></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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 4, 2018, at 2:55 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-8595388434919151480Apple-interchange-newline"><div class=""><div dir="auto" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class="m_-8595388434919151480Apple-interchange-newline">On Thu, Jan 4, 2018 at 17:15 Cheyo J. Jimenez <<a href="mailto:cheyo@masters3d.com" target="_blank" class="">cheyo@masters3d.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 4, 2018, at 11:53 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-8595388434919151480m_-6520709161405088222Apple-interchange-newline"><div class=""><div dir="auto" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class="m_-8595388434919151480m_-6520709161405088222Apple-interchange-newline">On Thu, Jan 4, 2018 at 13:46 Cheyo Jimenez <<a href="mailto:cheyo@masters3d.com" target="_blank" class="">cheyo@masters3d.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto" class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">On Jan 4, 2018, at 10:49 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" target="_blank" class="">jordan_rose@apple.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">I'll admit I hadn't thought of using "unknown default" (or "default unknown"). I don't think that's terrible, but I mildly prefer `unknown case` because it builds on the "pun" that enum elements are also defined using 'case'. If anything hits this part of the switch, it really will be an "unknown case", i.e. a statically-unknown enum element.<div class=""><br class=""></div><div class="">To Cheyo's point, if this<span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span><i class="">were</i> to be a single token I'd probably spell it #unknown, like #available. Then we'd have `case #unknown:` and something that naturally expands to other pattern positions. I found that less aesthetically pleasing, though, and so a context-sensitive keyword seemed like the way to go.</div><div class=""><br class=""></div><div class="">(For the record, though, I wouldn't describe `case _` as a special case of `default`. They do exactly the same thing, and `_` is a useful pattern in other contexts, so if anything the current `default` should be thought of as syntactic sugar for `case _`.)</div></div></blockquote><div class=""><br class=""></div></div><div dir="auto" class=""><div class="">Can case _ be mixed with unknown case? How can we match all compile time known cases but exclude future cases?</div></div></blockquote><div dir="auto" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><div dir="auto" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">What’s your use case for that? That eliminates the possibility of “unknown case” giving you compile-time warnings for subsequently added cases, which was the entire purpose of adding the syntax in the first place.</div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class=""><div class="">I was thinking of a generalized `unknown case` pattern but that is <a href="https://github.com/apple/swift-evolution/pull/777/files#diff-a68dc745ee86d09566b232b6954c5158R321" target="_blank" class="">out of scope for this proposal.</a> </div><div class=""><div class=""><br class=""></div><div class=""><div class="">switch excuse {</div><div class=""> case .eatenByPet :</div><div class=""> //…</div><div class=""> unknown case:</div><div class=""> // …</div><div class=""> case _:</div><div class=""> // …</div><div class=""> }</div></div></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto" class=""><div class="">Should there be something like `case *` that would capture all currently known cases during compile time? case * and case _ would be the same in exhaustive enums. </div></div></blockquote></div></blockquote><div class=""><br class=""></div><div class="">This is why I was suggesting another pattern that only captures known cases at compile time:</div><div class=""><br class=""></div><div class=""><div class="">switch excuse {</div><div class=""> case .eatenByPet :</div><div class=""> //…</div><div class=""><div class=""> case * : // All cases captured at compile time. </div><div class=""> // …</div></div><div class=""> unknown case:</div><div class=""> // …</div><div class=""> }</div></div></div></div><div style="word-wrap:break-word" class=""><div class=""></div></div></blockquote><div dir="auto" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><div dir="auto" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">Sorry, I don’t understand. However you spell it, what is your use case for this? The stated purpose of “unknown case” is to gain compile-time exhaustiveness testing, but this would not allow for that.</div></div></blockquote><div class=""><br class=""></div><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div><div style="word-wrap:break-word" class=""><div class=""><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;word-wrap:normal;padding:16px;overflow:auto;line-height:1.45;background-color:rgb(246,248,250);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal;color:rgb(36,41,46);font-variant-ligatures:normal" class=""><span class="m_-8595388434919151480pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">switch</span> (excuse, notifiedTeacherBeforeDeadline) {
<span class="m_-8595388434919151480pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">case</span> (.<span class="m_-8595388434919151480pl-smi" style="box-sizing:border-box">eatenByPet</span>, <span class="m_-8595388434919151480pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">true</span>)<span class="m_-8595388434919151480pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">:</span>
<span class="m_-8595388434919151480pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="m_-8595388434919151480pl-c" style="box-sizing:border-box">//</span> …</span>
<span class="m_-8595388434919151480pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span><span class="m_-8595388434919151480pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">case</span> (.<span class="m_-8595388434919151480pl-smi" style="box-sizing:border-box">thoughtItWasDueNextWeek</span>, <span class="m_-8595388434919151480pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">true</span>)<span class="m_-8595388434919151480pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">:</span>
<span class="m_-8595388434919151480pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="m_-8595388434919151480pl-c" style="box-sizing:border-box">//</span> …</span>
<span class="m_-8595388434919151480pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span><span class="m_-8595388434919151480pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">case</span> (unknown <span class="m_-8595388434919151480pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">case</span>, <span class="m_-8595388434919151480pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">true</span>)<span class="m_-8595388434919151480pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">:</span>
<span class="m_-8595388434919151480pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="m_-8595388434919151480pl-c" style="box-sizing:border-box">//</span> …</span>
<span class="m_-8595388434919151480pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span><span class="m_-8595388434919151480pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">case</span> (<span class="m_-8595388434919151480pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">_</span>, <span class="m_-8595388434919151480pl-c1" style="box-sizing:border-box;color:rgb(0,92,197)">false</span>)<span class="m_-8595388434919151480pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">:</span>
<span class="m_-8595388434919151480pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"><span class="m_-8595388434919151480pl-c" style="box-sizing:border-box">//</span> …</span>
<span class="m_-8595388434919151480pl-c" style="box-sizing:border-box;color:rgb(106,115,125)"></span>}</pre><div class=""><br class=""></div><div class="">Im referring to the future direction section in the <a href="https://github.com/jrose-apple/swift-evolution/blob/6061c01fb4a6d742ba7213f46979c9b82891fc14/proposals/0192-non-exhaustive-enums.md#future-directions" target="_blank" class="">new PR</a>. The above example if from there. </div><div class=""><br class=""></div><div class="">I am fine with `unknown case` being required to be at the end of the switch for now. </div><div class=""><br class=""></div><div class="">I think of `unknown case` as a pattern that only matches unknown cases no matter where on the switch it is.</div><div class=""><br class=""></div><div class="">This is why I do not think that `default unknown` would work well once `unknown case` can be used a pattern.</div><div class=""><br class=""></div><div class="">We can start a new thread on this if you’d like. </div><div class=""></div></div></div></blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">The reason I put forward “default unknown” is precisely because the proposed feature *cannot* be used in a pattern and therefore seems more apt as not a case.</div><div dir="auto" class=""><br class=""></div></div></div></div></blockquote>It can not be used in a pattern now but you could in the future if left as `case`. <br class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="gmail_quote"><div dir="auto" class="">It actually makes it more natural to use in the given example above because “default unknown” could actually be used to provide compile-time exhaustiveness checking for such a tuple pattern, whereas without being able to use “unknown case” in a pattern you can’t write “case (unknown case, _)”.</div></div></div></div></blockquote><div><br class=""></div><div>The way `unknown case` enforces compile-time exhaustiveness is by only matching unknown cases. The implementation may be more close to default by the virtue of being forced to go at the end of the switch statement now but that should not dictate the user experience. </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="gmail_quote"><div dir="auto" class=""><br class=""></div><div dir="auto" class="">You still haven’t answered my question, though—what’s the use case for the feature you propose?</div></div></div></div></blockquote><div><br class=""></div>My use case would be distinguishing between compile time known cases vs “future only” cases (or unknown cases). This depends on generalized `unknown case` patterns which is out of scope. I am happy to talk more about this on a different thread when this proposal gets approved. </div><div><br class=""></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="gmail_quote"><div dir="auto" class=""><br class=""></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=""><div class=""><div class=""><br class=""></div><div class=""> </div></div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><div dir="auto" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><br class=""></div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto" class=""><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">I'll add these points to the "Alternatives Considered" section in the PR later today.</div><div class=""><br class=""></div><div class="">Jordan<br class=""><div class=""><br class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jan 3, 2018, at 22:56, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-8595388434919151480m_-6520709161405088222m_-3214780750878788621Apple-interchange-newline"><div class="">As has already been said, “case unknown” is source-breaking because it conflicts with any real cases named “unknown”; “\unknown” looks like a key path but isn’t, and I wonder if it would potentially conflict with existing key paths.<br class=""><br class="">In any case, my point was not to bikeshed the “unknown” part, but to ask whether any consideration had been made to have the feature presented as a flavor of default instead of a flavor of case.<br class=""><br class=""><div class="gmail_quote"><div class="">On Wed, Jan 3, 2018 at 23:57 Cheyo Jimenez <<a href="mailto:cheyo@masters3d.com" target="_blank" class="">cheyo@masters3d.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto" class=""><div class=""></div><div class=""><br class=""></div><div class=""><br class="">On Jan 3, 2018, at 6:52 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">This is a very nice revision. One bikeshedding thought:<div class=""><br class=""></div><div class="">Since "unknown case" is presented as a special kind of "default", can't be mixed with "default", and can't be used in case patterns, why not "default unknown" (or "unknown default") instead of "unknown case"?</div></div></div></blockquote><div class=""><br class=""></div></div><div dir="auto" class="">`case _ :` is already a special case of default. <div class="">I’d rather have `case unknown :`</div><div class="">`unknown case :` is weird because of the order of `case`. </div><div class=""><br class=""></div><div class="">Another alternative is `case \unknown :`</div><div class="">`\unknown` would also allow pattern matching. </div></div><div dir="auto" class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, Jan 3, 2018 at 8:05 PM, Jordan Rose via swift-evolution<span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span><span class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span><span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><span class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 2, 2018, at 18:07, Jordan Rose <<a href="mailto:jordan_rose@apple.com" target="_blank" class="">jordan_rose@apple.com</a>> wrote:</div><br class="m_-8595388434919151480m_-6520709161405088222m_-3214780750878788621m_3038813019960738014m_4426090214486360640Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class=""><div class="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md" style="font-family:Helvetica,arial,sans-serif" target="_blank" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md</a>]</div><div class=""><br class=""></div><div class="">Whew! Thanks for your feedback, everyone. On the lighter side of feedback—naming things—it seems that most people seem to like '<b class="">@frozen</b>', and that does in fact have the connotations we want it to have. I like it too.</div><div class=""><br class=""></div><div class="">More seriously, this discussion has convinced me that it's worth including what the proposal discusses as a<span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span><b class="">'future' case</b>. The key point that swayed me is that this can produce a<span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span><i class="">warning</i> when the switch is missing a case rather than an<span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span><i class="">error,</i> which both provides the necessary compiler feedback to update your code and allows your dependencies to continue compiling when you update to a newer SDK. I know people on both sides won't be 100% satisfied with this, but does it seem like a reasonable compromise?</div><div class=""><br class=""></div><div class="">The next question is how to spell it. I'm leaning towards `unexpected case:`, which (a) is backwards-compatible, and (b) also handles "private cases", either the fake kind that you can do in C (as described in the proposal), or some real feature we might add to Swift some day. `unknown case:` isn't bad either.</div><div class=""><br class=""></div><div class="">I too would like to just do `unknown:` or `unexpected:` but that's technically a source-breaking change:</div><div class=""><br class=""></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px" class=""><div class="">switch foo {</div><div class="">case bar:</div><div class=""> <span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span>unknown:</div><div class=""> <span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span>while baz() {</div><div class=""> <span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span>while garply() {</div><div class=""> <span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span>if quux() {</div><div class=""> <span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span>break unknown</div><div class=""> <span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span>}</div><div class=""> <span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span>}</div><div class=""> <span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span>}</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">Another downside of the `unexpected case:` spelling is that it doesn't work as part of a larger pattern. I don't have a good answer for that one, but perhaps it's acceptable for now.</div><div class=""><br class=""></div><div class="">I'll write up a revision of the proposal soon and make sure the core team gets my recommendation when they discuss the results of the review.</div><div class=""><br class=""></div><div class="">---</div><div class=""><br class=""></div><div class=""><div class="">I'll respond to a few of the more intricate discussions tomorrow, including the syntax of putting a new declaration inside the enum rather than outside. Thank you again, everyone, and happy new year!</div></div></div></div></blockquote><br class=""></div></span><div class="">I ended up doing these in the opposite order, writing up the new proposal first and not yet responding to the discussion that's further out. You can read my revisions at<span class="m_-8595388434919151480m_-6520709161405088222Apple-converted-space"> </span><a href="https://github.com/apple/swift-evolution/pull/777" target="_blank" class="">https://github.com/apple/swift-evolution/pull/777</a>.</div><div class=""><br class=""></div><div class="">In particular, I want to at least address:</div><div class="">- Dave D and Drew C's points about versioned libraries / linking semantics of modules.</div><div class="">- Jason M's point about migration</div>and I'll do one more pass over the thread to see if there's anything else I didn't address directly. (That doesn't mean everyone who disagrees, just messages where I think there's more I can do to explain why the proposal is the way it is.)<div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><div class="">P.S. Enjoying the Disney references. Thanks, Nevin and Dave. :-)</div></div><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class=""></blockquote></div><br class=""></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div></div></blockquote></div></div></blockquote></div></div></div></div></div></blockquote></div></blockquote></div></blockquote></div></div></blockquote></div></blockquote></div><br class=""></div></blockquote></div></div>
</div></blockquote></div><br class=""></body></html>