<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 <<a href="mailto:mark.lacey@apple.com" class="">mark.lacey@apple.com</a>> 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 <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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 <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 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: <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 </<=/>/>= 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?”. 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: <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. </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);">-></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”. 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 the code.” </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. 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). 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 Optional() (preferable) or alternately .some(). We could also consider adding a new top-level function for this purpose, but unless it provides additional clarity, it seems like Optional() 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” -> Can you explicitly share the name of any of the projects?</div><div class=""><br class=""></div><div class="">Otherwise, LGTM. 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>