<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 12, 2016, at 12:16 AM, 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="">Okay, I guess it's fair that (T, T?) and (T?, T) overloads should have to be a separate proposal.<div class=""><br class=""></div><div class="">My personal motivation is mostly anecdotal; I've found them quite useful, and I wouldn't say they're uncommon.</div></div></div></blockquote><div><br class=""></div><div>Sure, I mean uncommon in the sense that in the projects I’ve looked at I’m seeing them perhaps once every 1,000-2,000 lines of commented code, not uncommon in the sense that you will almost never see them in practice. I’m sure for some projects it’s going to be much more often than others.</div><div><br class=""></div><div>Mark</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> Some use cases off the top of my head:<div class="">- checking whether a dictionary contains a particular value for a key</div><div class="">- checking whether an optional ivar (such as "selectedIndex: Int?") contains a particular value ("if tappedIndex == selectedIndex”)</div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class=""><div 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 Tue, Jul 12, 2016 at 12:09 AM, 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=""><span class=""><blockquote type="cite" class=""><div class="">On Jul 11, 2016, at 11:55 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" target="_blank" class="">jtbandes@gmail.com</a>> wrote:</div><br class=""><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></span>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><span class=""><font color="#888888" class=""><div class=""><br class=""></div><div class="">Mark</div></font></span><span class=""><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 data-smartmail="gmail_signature" class=""><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=""><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=""></span></div></blockquote></div><br class=""></div></div></div></div></div>
</div></blockquote></div><br class=""></body></html>