Deprecate `$` as bitwise exclusive or to free ascii-char `$` for more useful purpose

[davidavdav]

As I tried to discuss here I believe that $ is a waste of single ascii character operator space. xor() would probably read just as easy. (Unfortunately, the discussion quickly derailed towards the concatenation operator * for strings).

I think in the mean time $ is dispatched for more types than just (Bool, Bool), which is rather unfortunate. For Bool types, the operator could be replaced by ^. (Currently x::Bool ^ y::Bool has the semantics of "y implies x", which was not intended IMHO). [@jiahao: edited from discussion below; ^ is exponentiation]

It would be great to have $ free/deprecated before julia-0.6/1.0 is finalised. My personal favourite is that x$y is, somehow, interpreted as x[:y]. See also the the discussion at #1974 .

[stevengj]

If we want x.y overloading (I do!), we should just implement that. (Note that you really want something like x[Val{:y}] so that it can be dispatched at compile-time.)

I don't think it would be a good idea to use ^ for both xor and exponentiation.

That being said, I'm inclined to agree that xor is uncommon enough that there's no need to define an ASCII binary operator for it. We could just use xor(a,b), and maybe const ⊻ = xor (\veebar<tab>).

[JeffBezanson]

I agree this is a waste of an ASCII operator. I might even extend the argument to | and & as well.

x::Bool ^ y::Bool is exponentiation. For 0 and 1 arguments ^ happens to have the same truth table as "implies".

[carnaval]

For 0 and 1 arguments ^ happens to have the same truth table as "implies".

(not a coincidence, this is Curry-Howard :-))

[Sacha0]

I agree this is a waste of an ASCII operator. I might even extend the argument to | and & as well.

+1, and in event of consensus I would lend a hand in the deprecation effort. Ref. #5187 and #5238.

[stevengj]

| and & are really useful as non short-circuit boolean operators, so I would prefer to leave them as-is.

[tkelman]

not entirely as is, we should deprecate the vectorized | and & now that dot operators are becoming more widespread and will be part of the syntax. $ is used for a few too many things and wouldn't be missed quite as much in infix. a unicode version would do fine.

[TotalVerb]

👎 to using ^ for Bool types. It would be incredibly confusing to have different semantics of ^ for Bool and Int.

[davidavdav]

x::Bool ^ y::Bool is exponentiation

I figured that, I just thought that false ^ false referring to 0^0 would be undefined. But I see now that 0^0==1 for all numeric types. But anyway, let's not discuss using ^ for xor() any further, that was probably a bad idea.

[jiahao]

Did someone say Unicode? ⊻ is not defined...

I edited the OP to reflect the discussion of ^ being exponentiation.

[StefanKarpinski]

Here's my position:

• I'm all for getting rid of $ as infix xor. We can just have a function called xor.
• Unless we have an equally intuitive meaning for & and | I don't see much point in getting rid of their current meanings, since the other usage would just be more confusing.
• Bool^Bool cannot mean xor since that's operator punning which is the most basic no-no.

[JeffBezanson]

Sounds like it is resolved to deprecate $ to xor.

[davidavdav]

Great! Will anyone pick this up or should I dig into the code and try to submit a PR?

[omus]

I'd like to maintain having infix operators for all bitwise operations. Using a unicode operator such as ⊻ or ⊕ (\oplustab) would be fine for this purpose.

[omus]

Alternatively, since bitwise operators aren't used very frequently we could always use a macro and stick to the traditional C bitwise operators.

@bitwise a ^ b  # XOR
a ^ b  # Exponentiation

I could also see this leading to confusion. Just a thought.

[TotalVerb]

I'm ok with ⊻ (\veebar), but ⊕ is too useful for other stuff to be used for XOR, IMO.