∧ and ∨ as aliases for && and ||

[ViktorQvarfordt]

Allow use of unicode symbols ∧ and ∨ as aliases for && and ||, respectively.

This is in line with existing unicode aliases, such as:

• ≤ = <=
• ≥ = >=
• ≠ = !=
• ∈ = in
• ⊆ = issubset

Furthermore, I suggest ¬ as alias for !.

The purpose of these aliases is, of course, to allow use of standard mathematical/logical symbols, hence also making the code more readable.

(Note that this is not related to #5238. I am strictly talking about aliases, not replacing or removing anything, nor changing any precedences.)

[yuyichao]

Note that these are totally different from other unicode alias since these are not functions at all.

[TotalVerb]

These symbols are standard notation for meets and joins. Short circuit boolean-only behavior would be terrible.

[oxinabox]

Giving them non-short-circuiting behaviour, which can be implemented as a function makes some sense.
either by aliasing them to | and & which would give them all the various (mostly bitwise) definitions.
Or by defining them for bools directly (and redefining) | and & in terms of them

That way they can still be overloaded as functions, so they can be redefined for other uses like Join and Meet and External Product

[ViktorQvarfordt]

I see the problems with this, as indicated by @yuyichao and @TotalVerb. However, I like the idea of @oxinabox.

[rleegates]

Just to pitch in, another use-case which stands against this is the definition of the wedge product of differential forms.

[TotalVerb]

I would also be against aliasing these to bitwise operations. I don't see how defining them on integers is a good idea. However, perhaps a definition for Tuple{Bool, Bool} that delegates to bitwise operations is OK.

[StefanKarpinski]

Since these are not just normal functions but control flow operators, I think that introducing alternate forms for them would be a very bad idea. For really basic language constructs like control flow you don't want too much diversity in how to spell things. Providing aliases for functions is a much different matter.

[andyferris]

I agree with @StefanKarpinski. But they could be a function, specialized for ∨(::Bool, ::Bool), etc, and letting everyone else doing meets and joins and wedge products on their types, and have them as a binary operator.

However, perhaps a definition for Tuple{Bool, Bool} that delegates to bitwise operations is OK.

In this case (and for any collection of Bools) .∧ and .∨ would already make perfect sense, no?

[TotalVerb]

@andyferris Such a definition is what I meant. I think that meaning would be uncontroversial.

[KristofferC]

Doesn't look like much more discussion is warranted here. See #19788 for something that at least has a chance of happening.