<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="">An example to keep in mind:<div class=""><br class=""></div><div class="">let dict: [String : String] = ...</div><div class="">if dict["key"] == "value" { // String? == String</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// Do something</div><div class="">}</div><div class=""><br class=""></div><div class="">If I understand correctly, when the proposal is accepted, you'd need to do something like:</div><div class=""><br class=""></div><div class="">if let value = dict["key"], value == "value" { } </div><div class="">-- OR --</div><div class="">if dict["key"] == Optional("value") { }</div><div class=""><br class=""></div><div class="">It's not an end of the world, but makes life a bit more difficult and such usecase should be kept in mind.</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 12, 2016, at 9:09 AM, Mark Lacey 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 11:55 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Mark,<div class="">Thanks for writing this up. Just to clarify, will these still work if your proposal is implemented?</div><div class=""><br class=""></div><div class=""> let x: Int?</div><div class=""> let y: Int</div><div class=""> struct NotEquatable {}<br class=""></div><div class=""> let z: NotEquatable?</div><div class=""><br class=""></div><div class=""> x == y; x != y</div><div class=""> x == nil; x != nil</div><div class=""> z == nil; z != nil</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">I would hope that these continue to work. If any changes need to be made to ensure that, please make sure they're included in the proposal too.</div></div></div></blockquote><div class=""><br class=""></div>The last four would work, but the first two (x == y and x != y) would not because they still involve coercing y to an optional.</div><div class=""><br class=""></div><div class="">Similarly, === and !== on reference types where one is an optional would require coercing one side, and would not be accepted without an explicit cast using Optional().</div><div class=""><br class=""></div><div class="">I’m curious what the motivation is for further special casing these operators. They do occur more in practice than <, <=, >, >= (in fact most of the source updates I had to make were due to === and !==, with == and != a close second), but overall these are still quite uncommon from what I’ve seen.</div><div class=""><br class=""></div><div class="">If you’d like I can certainly update the “alternatives considered” to include the suggestion that we add overloads for (T, T?) and (T?, T) for those four operators.</div><div class=""><br class=""></div><div class="">Mark</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr" class=""><div class="">Jacob<br class=""></div></div></div></div>
<br class=""><div class="gmail_quote">On Mon, Jul 11, 2016 at 9:35 PM, Mark Lacey <span dir="ltr" class=""><<a href="mailto:mark.lacey@apple.com" target="_blank" class="">mark.lacey@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><div class=""><div class="h5"><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" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" 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" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class=""><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" target="_blank" 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" target="_blank" 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></div></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" target="_blank" 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><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Mark</div></font></span><span class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><br class=""></div>_______________________________________________<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" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></span></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>