<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=""><div class="">Can someone fill me in as to how this differs from (0…4).contains(x)?</div><div class=""><br class=""></div><div class="">Personally I don’t like the choice for the operator, and think it’s not very clear, if we can do the same thing with a method then I’d prefer removing the operator to be honest.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 7 Apr 2016, at 12:57, David Rodrigues 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 style="font-size:12.8px" class="">Hi all,</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">Swift has a pattern match operator, ~=, which is unknown to many (like me until a few weeks ago), that performs a match between a value and a certain pattern, e.g. checking if an integer value is contained in a range of integers.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">This operator may be little known, but it plays a key role in the language since it's used behind the scenes to support expression patterns in `switch` statement case labels, which we all know are extremely popular.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">let point = (2, 4)</div><div style="font-size:12.8px" class="">switch point {</div><div style="font-size:12.8px" class="">case (0, 0):</div><div style="font-size:12.8px" class="">&nbsp; &nbsp; print("The point is at the origin")</div><div style="font-size:12.8px" class="">case (0...4, 0...4):</div><div style="font-size:12.8px" class="">&nbsp; &nbsp; print("The point is in the subregion")</div><div style="font-size:12.8px" class="">default:</div><div style="font-size:12.8px" class="">&nbsp; &nbsp; break</div><div style="font-size:12.8px" class="">}</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">Most of the time we don't use the operator directly but it is available and can be handy in certain conditions.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">let point = (2, 4)</div><div style="font-size:12.8px" class="">switch point {</div><div style="font-size:12.8px" class="">case (let x, let y) where 0...4 ~= x &amp;&amp; 0...4 ~= y:</div><div style="font-size:12.8px" class="">&nbsp; &nbsp; print("The point is in the subregion")</div><div style="font-size:12.8px" class="">default:</div><div style="font-size:12.8px" class="">&nbsp; &nbsp; break</div><div style="font-size:12.8px" class="">}</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">However the current syntax is not ideal (in my opinion). We're not really declaring the operation that we want to do, and that has an impact in the expressivity and readability of the code. Currently we're doing matches like "if blue is the ocean" instead of "if the ocean is blue" or "if the ocean contains the whale" instead of "if the whale is in the ocean".</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">For that reason, I would like to suggest inverting the order of the operator to match more closely our logical thought.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">case (let x, let y) where x =~ 0...4 &amp;&amp; y =~ 0...4: // Proposed</div><div style="font-size:12.8px" class="">// vs</div><div style="font-size:12.8px" class="">case (let x, let y) where 0...4 ~= x &amp;&amp; 0...4 ~= y: // Current</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">I have an ongoing proposal to suggest this change and it contains a little more context. It is available here:&nbsp;</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class=""><a href="https://github.com/dmcrodrigues/swift-evolution/blob/proposal/invert-order-of-pattern-match-operator/proposals/NNNN-invert-order-of-pattern-match-operator.md" target="_blank" class="">https://github.com/dmcrodrigues/swift-evolution/blob/proposal/invert-order-of-pattern-match-operator/proposals/NNNN-invert-order-of-pattern-match-operator.md</a>.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">Any feedback is very welcome.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">Thank you.</div><div style="font-size:12.8px" class=""><br class=""></div><div style="font-size:12.8px" class="">David Rodrigues</div></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=""></body></html>