Replace && and || with and and or

[johnmyleswhite]

As discussed at length in #5187, many of us would prefer that && be written as and and || be written as or.

[goszlanyi]

+1
I would really like to see this happen.
More readable like end used for indexing.

[gitfoxi]

+1
On Dec 27, 2013 1:06 PM, "GaborOszlanyi" notifications@github.com wrote:

+1
I would really like to see this happen.
More readable like end used for indexing.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/5238#issuecomment-31280112
.

[ViralBShah]

I like this suggestion too.

[StefanKarpinski]

I'm a bit surprised by the groundswell of support this is getting. I've always felt that the spelled out operators were much more intuitive for control flow, but I didn't realize the feeling was widespread.

[nalimilan]

I was not a fan when you made this proposition, but I must say after some more thinking it also makes much sense to me. These are really control flow operators, in contrast with all others, which use symbols rather than text. This may reduce the confusion with & and |.

I've noticed that the languages which provide and and or (Perl, Ruby, Lua -- for the ones I checked) also provide not (Lua even does not offer !). My first reaction is that I don't like it, since it's redundant with !. But maybe there's a strong reason why these languages chose to do so.

[johnmyleswhite]

I personally like not a lot, but don't think that switching to not offers anything like the reduction in ambiguity that using and and or provide.

[ivarne]

not is not a short circuit/control flow operation either, and I always struggle with how to read it with regards to associativity. The only place I like it in Pyhton is the if not ... but that is because I read it as a control flow operation.

[diegozea]

+1

Can also be added XOR as short circuit ?
And short circuit version of the inverted versions (XNOR,NAND,NOR) ?

[StefanKarpinski]

XOR is never short-circuitable. The other ones can be trivially written with ! plus the and and or operators.

[malmaud]

+1
I'll point out that in Ruby, there's constant confusion about && vs 'and' (http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/), so it would be good if we kept in mind the rational that Ruby uses to have both sets of operators and decide whether its worth the confusion or if && should be removed completely in favor of 'and'.

[StefanKarpinski]

I would prefer for and and or to have super-low precedence like they do in Perl and Ruby so that you can write things like

k <= n and k *= 2

[JeffBezanson]

Sometimes you want to assign the boolean result to something:

cond = f() && g()

Which seems to conflict with that.

[StefanKarpinski]

Well, that's precisely why Ruby and Perl have both sets of operators with different precedence. Not advocating for that, but just saying. I'm not sure how common that usage actually is, whereas grepping through our code reveals a lot of k <= n && (k *= 2) kinds of things.

[toivoh]

Firstly, I'm also for and and or.
I see that lowest four precedence groups in Julia right now are

1. Assignments including += etc., :=, =>, and ~
2. The ternary operator ?
3. ||
4. &&

I think that this makes good sense (not sure about ~, but that's beside the point). Logical and and or are useful both as right hand side of assignments and condition of ?. If you are going to use either an assignment or ternary operator as argument to and or or, I think you know that you are doing something unusual and that parentheses are in order.

[toivoh]

Btw, I think that a lot of people would expect that a language that uses and and or for logical operations would use not for logical negation. But if we have good reason to keep !, that might be ok. (I guess that ! is not strictly just logical negation, at least if #4892 is implemented is merged.)