<div dir="ltr">I wrote these a while ago and considered proposing that they be added. Might as well throw them into this thread since they are another approach to solving the problem.<br><br><br><div>``` swift</div><div>import Foundation</div><div>    // MARK: &lt;</div><div>    public func &lt;&lt;T : Comparable&gt;(lhs: T, rhs: T) -&gt; (result: Bool, value:T) {</div><div>        return (lhs &lt; rhs, rhs)</div><div>    }</div><div>    </div><div>    public func &lt;&lt;T : Comparable&gt;(lhs: (result: Bool, value: T), rhs: T) -&gt; Bool {</div><div>            return lhs.result &amp;&amp; (lhs.value &lt; rhs)</div><div>        }</div><div>        </div><div>    public func &lt;&lt;T : Comparable&gt;(lhs: (Bool, T), rhs: T) -&gt; (Bool, T) {</div><div>            return (lhs &lt; rhs, rhs)</div><div>        }</div><div>        </div><div>// MARK: &gt;</div><div>public func &gt;&lt;T : Comparable&gt;(lhs: T, rhs: T) -&gt; (result: Bool, value:T) {</div><div>    return (lhs &gt; rhs, rhs)</div><div>    }</div><div><br></div><div>public func &gt;&lt;T : Comparable&gt;(lhs: (result: Bool, value: T), rhs: T) -&gt; Bool {</div><div>    return lhs.result &amp;&amp; (lhs.value &gt; rhs)</div><div>    }</div><div><br></div><div>public func &gt;&lt;T : Comparable&gt;(lhs: (Bool, T), rhs: T) -&gt; (Bool, T) {</div><div>    return (lhs &gt; rhs, rhs)</div><div>    }</div><div>// MARK: &gt;=</div><div>public func &gt;=&lt;T : Comparable&gt;(lhs: T, rhs: T) -&gt; (result: Bool, value:T) {</div><div>    return (lhs &gt;= rhs, rhs)</div><div>    }</div><div><br></div><div>public func &gt;=&lt;T : Comparable&gt;(lhs: (result: Bool, value: T), rhs: T) -&gt; Bool {</div><div>    return lhs.result &amp;&amp; (lhs.value &gt;= rhs)</div><div>    }</div><div><br></div><div>public func &gt;=&lt;T : Comparable&gt;(lhs: (Bool, T), rhs: T) -&gt; (Bool, T) {</div><div>    return (lhs &gt;= rhs, rhs)</div><div>    }</div><div><br></div><div>// MARK: &lt;=</div><div>public func &lt;=&lt;T : Comparable&gt;(lhs: T, rhs: T) -&gt; (result: Bool, value:T) {</div><div>    return (lhs &lt;= rhs, rhs)</div><div>    }</div><div><br></div><div>public func &lt;=&lt;T : Comparable&gt;(lhs: (result: Bool, value: T), rhs: T) -&gt; Bool {</div><div>    return lhs.result &amp;&amp; (lhs.value &lt;= rhs)</div><div>    }</div><div><br></div><div>public func &lt;=&lt;T : Comparable&gt;(lhs: (Bool, T), rhs: T) -&gt; (Bool, T) {</div><div>    return (lhs &lt;= rhs, rhs)</div><div>    }</div><div><br></div><div>// MARK: ==</div><div>public func ==&lt;T : Comparable&gt;(lhs: T, rhs: T) -&gt; (result: Bool, value:T) {</div><div>    return (lhs == rhs, rhs)</div><div>    }</div><div><br></div><div>public func ==&lt;T : Comparable&gt;(lhs: (result: Bool, value: T), rhs: T) -&gt; Bool {</div><div>    return lhs.result &amp;&amp; (lhs.value == rhs)</div><div>    }</div><div><br></div><div>public func ==&lt;T : Comparable&gt;(lhs: (Bool, T), rhs: T) -&gt; (Bool, T) {</div><div>    return (lhs == rhs, rhs)</div><div>    }</div><div>let value = 5</div><div><br></div><div>if (0 &lt; value) &lt; 10 {</div><div>    print(&quot;in the middle!&quot;)</div><div>    } else {</div><div>    print(&quot;nope&quot;)</div><div>    }</div><div><br></div><div>```</div><br>On Sun, Mar 27, 2016 at 5:19 AM, Lukas Stabe via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>&gt;<br>&gt; I&#39;d love to see `if value matches pattern`. Every time I use `if case` I have to stop and think to remember the weird syntax. I get where it came from, but I think `matches` better describes what happens here (one is immediately reminded of pattern matching).<br>&gt;<br>&gt; I don&#39;t know wether this might be unfeasible to do due to compiler performance limitations, but I would support a proposal to replace `if case` with `if value matches pattern`. <br>&gt;<br>&gt; An alternative may be to introduce a custom operator that just calls `~=` with the arguments reversed, but imho this should rather be fixed at the language level.<br>&gt;<br>&gt; – Lukas<br>&gt;<br>&gt; On 26 Mar 2016, at 18:13, Erica Sadun via swift-users &lt;<a href="mailto:swift-users@swift.org">swift-users@swift.org</a>&gt; wrote:<br>&gt;<br>&gt; On Mar 26, 2016, at 3:47 PM, Maury Markowitz via swift-users &lt;<a href="mailto:swift-users@swift.org">swift-users@swift.org</a>&gt; wrote:<br>&gt;<br>&gt; Before I stick my head into the other list, consider:<br>&gt;<br>&gt;   if statusCode &gt;= 200 &amp;&amp; statusCode &lt;= 299<br>&gt;<br>&gt; I&#39;m sure examples of something like this occur throughout your code. But the actual semantics of the test is hidden here, you&#39;re really testing if statusCode lies within a range. Swift 2.0 has a couple of options for this, but I find them all rather odd. The most recommended is:<br>&gt;<br>&gt;   if case 0...100 = someInteger<br>&gt;<br>&gt;<br>&gt; While I prefer: <br>&gt;<br>&gt; if 200...299 ~= statusCode { print(&quot;within 200-299&quot;) }<br>&gt;<br>&gt; I see that you&#39;re asking specifically about case/=. But keep that example in mind because I&#39;m<br>&gt; going to circle back to it.<br>&gt;<br>&gt; This syntax has problems. For one thing, it&#39;s written backwards compared to most people&#39;s code...<br>&gt;<br>&gt;   if someinteger == 100<br>&gt;<br>&gt; not...<br>&gt;<br>&gt;   if 100 == someinteger<br>&gt;<br>&gt; so it just *feels* wrong. In addition, the use of &quot;case&quot; seems odd too. And finally, there&#39;s the use of the single equals sign in a test, which goes against everything we&#39;ve learned in C-like languages.<br>&gt;<br>&gt; So unless I&#39;m missing something, can anyone offer a reason this wouldn&#39;t work?<br>&gt;<br>&gt;  if someinteger in 0...100<br>&gt;<br>&gt;<br>&gt; This is a built-in problem with &quot;if case/=&quot;. Starting with the core statement :<br>&gt;<br>&gt; if case pattern = value {...}<br>&gt;<br>&gt; It&#39;s far easier to read and understand the equivalent switch than the one-liner:<br>&gt;<br>&gt; switch (value) {<br>&gt; case pattern: ...<br>&gt; default: break<br>&gt; }<br>&gt;<br>&gt; Once you convert to a switch, the &quot;If this value can be matched to this pattern&quot; <br>&gt; becomes a lot less mentally weird but there&#39;s also a lot of extra fluff that if case<br>&gt; attempts to trim away. Here&#39;s a concrete example.  &quot;In the case that the pattern <br>&gt; Test.A(Int) can be matched to this value then bind x to the associated Int value&quot;<br>&gt;<br>&gt; let value = Test.A(23)<br>&gt;<br>&gt; if case Test.A(let x) = value {<br>&gt;     print(x) // will print 23<br>&gt; }<br>&gt;<br>&gt; Again the switch is a lot more intuitive to read, but contains a lot of unneeded<br>&gt; details that can and should be trimmable:<br>&gt;<br>&gt; switch (value) {<br>&gt; case Test.A(let x): ...<br>&gt; default: break<br>&gt; }<br>&gt;<br>&gt; And here&#39;s the oddest example of this Case/= construct I can think of in terms<br>&gt; of the &quot;read through&quot; not matching the actual programming intent of &quot;In the <br>&gt; case that the array indices can be matched to this value&quot; <br>&gt;<br>&gt; if case array.indices = array.startIndex { print(&quot;strange but yup&quot;) }<br>&gt;<br>&gt; And its switch equivalent, which is way more obvious in terms of intent:<br>&gt;<br>&gt; switch (array.startIndex) {<br>&gt; case array.indices: ...<br>&gt; default: break<br>&gt; }<br>&gt;<br>&gt; Now back to your original point. Could this be expressed better? For sure. I think these are far more readable:<br>&gt;<br>&gt; if value in range {...} // vs if range ~=<br>&gt; if value matches pattern {...} // vs if case pattern = value<br>&gt;<br>&gt; And for these specific examples, they&#39;d look like this in an updated Swift that adopted these changes:<br>&gt;<br>&gt; if statusCode in 200...299 { print(&quot;within 200-299&quot;) }<br>&gt; if value matches Test.A(let x) { print(x) } // will print 23<br>&gt; if array.startIndex in array.indices { print(&quot;the ~= variation&quot;) }<br>&gt; if array.startIndex matches array.indices { print (&quot;better example Case/=&quot;) }<br>&gt;<br>&gt; That said, I&#39;ve also made my opinion clear over there that the use of &quot;let&quot; and &quot;var&quot;<br>&gt; in &quot;if let&quot; unnecessarily overloads constant and variable binding (it&#39;s testing something <br>&gt; that actually acts differently than the standalone let due to unwrapping). This got nowhere<br>&gt; for a variety of compelling and less compelling reasons. (I&#39;d prefer &quot;if bind&quot; even if it  <br>&gt; sacrifices a variable variant.)<br>&gt;<br>&gt; I certainly think it&#39;s worth doing at least a [Pitch] over in -evolution with the alternate <br>&gt; constructs.<br>&gt;<br>&gt; -- E<br>&gt;<br>&gt; _______________________________________________<br>&gt; swift-users mailing list<br>&gt; <a href="mailto:swift-users@swift.org">swift-users@swift.org</a><br>&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-users">https://lists.swift.org/mailman/listinfo/swift-users</a><br>&gt;<br>&gt;<br>&gt; _______________________________________________<br>&gt; swift-evolution mailing list<br>&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>&gt;<br></div>