I&#39;m not sure how you&#39;re coming up with &quot;domain areas&quot;. Ranges have numbers as bounds; those are typically computed by arithmetic.<br><br>Virtually the entire stdlib exists to support language features; all other facilities found in other languages&#39; &quot;standard library&quot; are in Foundation.<br><br>As I mentioned, theoretical justifications have no sway with me. Show me how a real user error is averted by such a change. I see none here; thus, I disagree with the change.<br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 2, 2016 at 14:45 Anton Zhilin &lt;<a href="mailto:antonyzhilin@gmail.com">antonyzhilin@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If operator &lt;+&gt; is used in one domain area, and operator &lt;-&gt; is used in another domain area, then we should not make everyone keep in mind both domain areas simultaneously.<div><br><div>Another explanation: operator ... does not belong to &quot;core&quot;, &quot;control&quot; operators, it belongs to Ranges part of standard library. Likewise, + operates on numbers. Therefore they should not have precedence relationship.</div><div><br></div><div>Yet another explanation: I believe that optionals and booleans are a lot more fundamental in Swift than ranges. Ranges don&#39;t have any support in language itself, they belong to standard library.</div></div></div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-08-02 22:19 GMT+03:00 Xiaodi Wu <span dir="ltr">&lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What&#39;s the benefit? Is there anyone confused by a...b+c?<div><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 2, 2016 at 14:13 Anton Zhilin &lt;<a href="mailto:antonyzhilin@gmail.com" target="_blank">antonyzhilin@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-08-02 21:56 GMT+03:00 Xiaodi Wu <span dir="ltr">&lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt;</span>:<br></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I can sort of see what this is getting at, but I simply have no way of evaluating whether it&#39;s sensible or not without actual examples in code. This is, again, a more expansive change than discussed. I&#39;d be interested in seeing your write-up on separating arithmetic and bitwise/bitshift operators :)</div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 2, 2016 at 1:36 PM, Anton Zhilin <span dir="ltr">&lt;<a href="mailto:antonyzhilin@gmail.com" target="_blank">antonyzhilin@gmail.com</a>&gt;</span> wrote:</div></div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Here&#39;s another possible plan:</div><div><a href="https://gist.github.com/Anton3/e00026409a6f948ca3ba41acf24e9672" target="_blank">https://gist.github.com/Anton3/e00026409a6f948ca3ba41acf24e9672</a><br></div><div><br></div><div>There is a base line of &quot;core&quot;, control-like operators, which everyone must know. &quot;Applied&quot; operators are branched off them. For example, Ternary, Comparison or Casting can be selected as base for a new mini-tree of related operators.</div><div><br></div><div>Following this scheme, there are at least 3 &quot;applied&quot; domains with operators: arithmetic, bitwise and range formation. You can see result in the gist.</div></div></div></div></blockquote></div></div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote"></div></div></div></div></blockquote><div><br></div><div>Well, I don&#39;t suggest changing precedence relationships there (just removing some), so that should be on-topic, I guess?</div><div><br></div><div>The main change I suggest over separating bitwise operators is separating RangeFormation, because it&#39;s a separate, &quot;applied&quot; operator domain. It is not control-structure-like, so it does not deserve to be in the main tree.</div><div><br></div><div>Simplifying even more, I want to prohibit this:  a...b+c</div></div></div></div>
</blockquote></div>
</div></div></blockquote></div><br></div></div></blockquote></div>