<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 Jul 11, 2016, at 9:35 PM, Mark Lacey &lt;<a href="mailto:mark.lacey@apple.com" class="">mark.lacey@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 11, 2016, at 9:12 PM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 11, 2016, at 8:14 PM, Jacob Bandes-Storch via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">You'd have to unwrap it, or use the ??/==/!= operators:&nbsp;<a href="https://gist.github.com/jtbandes/9d88cc83ceceb6c62f38" class="">https://gist.github.com/jtbandes/9d88cc83ceceb6c62f38</a></div><div class=""><br class=""></div><div class="">I'd be okay with &lt;/&lt;=/&gt;/&gt;= returning Bool?, as I suggested in an older email (which somehow didn't make it to gmane's archive, but it's quoted in <a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/10095" class="">some other messages</a>). I think it would be more convenient in some cases than unwrapping the individual values before comparing them.</div></div></div></blockquote><br class=""></div><div class="">I’d be strongly opposed to those operator returning “Bool?”. &nbsp;Doing so would prevent conforming to Comparable and would be extremely surprising.</div><div class=""><br class=""></div><div class="">-Chris</div></div></div></blockquote><div class=""><br class=""></div>I just pushed the current draft of the proposal:&nbsp;<a href="https://github.com/rudkx/swift-evolution/blob/eliminate-value-to-optional-coercion/proposals/0000-disallow-value-to-optional-coercion-in-operator-arguments.md" class="">https://github.com/rudkx/swift-evolution/blob/eliminate-value-to-optional-coercion/proposals/0000-disallow-value-to-optional-coercion-in-operator-arguments.md</a></div><div class=""><br class=""></div><div class="">I haven’t addressed removal of the ordered comparison operators. I suspect this should be a separate proposal, but I can roll that into this one if it’s desired.</div><div class=""><br class=""></div><div class="">I’ll update the proposal as the discussion continues until it’s selected for review.</div></div></div></blockquote><br class=""></div><div>I think it makes sense to keep removal of the non-equality comparisons a separate proposal.</div><div><br class=""></div><div>Here are some nit-picky comments:</div><div><br class=""></div><div>I’d suggest adding quotes:</div><div><br class=""></div><div>… by making the notion of “having" or "not having" a value explicit.&nbsp;</div><div><br class=""></div><div>Missing a let/var before the first x in:</div><div><br class=""></div><div><pre style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(247, 247, 247); 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(51, 51, 51);" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">func</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">returnsOptional</span>() <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">-&gt;</span> <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Int</span>? {
  x: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Int</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">...</span>
  <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">return</span> x
}</pre><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I would move “Proposed Solution” before “Motivation” and just call it “Proposal”. &nbsp;Otherwise the motivation section doesn’t make sense to read in order.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I’d add to this:</div><div class="">"Both of these examples represent cases where the silent behavior could potentially hide bugs or confuse readers of&nbsp;the code.” &nbsp;</div><div class=""><br class=""></div><div class="">… “, it would be better to reject the code as a type error."</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">If this is relating to implementation details of the standard library, then it should be omitted from the proposal. &nbsp;The following paragraph also makes sense to revise if you drop this:</div><div class="">"Additionally the standard library has approximately a half a dozen locations where optionals are compared to non-optional values which will need to be updated to explicitly cast one operand to an optional.”</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">In this paragraph, I’d recommend changing the wording to be specific and opinionated (saying that “Optional” is the right answer). &nbsp;If you want to raise specific alternatives for consideration, please add it to “alternatives considered” at the end:</div><div class="">"This conversion can currently be accomplished by using&nbsp;Optional()&nbsp;(preferable) or alternately&nbsp;.some(). We could&nbsp;also consider adding a new top-level function for this purpose, but unless it provides additional clarity, it seems like&nbsp;Optional()&nbsp;is reasonable and quite prominent."</div><div class=""><br class=""></div><div class="">Keeping the body of the proposal opinionated makes the review periods more useful because people know what is specifically being proposed.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">"In a survey of six projects” -&gt; Can you explicitly share the name of any of the projects?</div><div class=""><br class=""></div><div class="">Otherwise, LGTM. &nbsp;When you’re happy with it, please submit a PR for swift-evolution repo, I’ll review managerize it,</div><div class=""><br class=""></div></div><div>-Chris</div><br class=""></body></html>