allow ± and ∓ as unary operators

[simeonschaub]

This came up on slack, that it would be nice to have ± as an allowed unary operator. This PR also adds ∓. further plus-like operators, which looked enough like + and - to make sense in my mind, but I can also remove the weirder ones, if so desired. Probably should have tests, but I'm not quite sure what to test here exactly.

[JeffBezanson]

Will have to decide how to transition the parsing of e.g. [1 ±2].

[tkf]

I suppose merging this PR would make #33859 more breaking?

[JeffBezanson]

Strictly speaking yes, but these operators are used much less often than + and -.

[stevengj]

I'm skeptical that all of these operators should be unary. ± and ∓, certainly, but is there any example in the literature of the other operators being unary? It's easier to be conservative here.

[JeffBezanson]

Probably should not include ≏ "difference between", which doesn't make sense for 1 argument.

[JeffBezanson]

Let's cut this down to just ± and ∓, which are obviously useful, and run PkgEval to see if anything breaks.

[simeonschaub]

@JeffBezanson That seems like a good plan. Adding further operators can always be discussed later, so it makes sense to keep this more minimal. Could someone trigger PkgEval?

[StefanKarpinski]

@nanosoldier runtests(ALL, vs=":master")

[StefanKarpinski]

I think I did that right? 🤷‍♂

[nanosoldier]

Your package evaluation job has completed - possible new issues were detected. A full report can be found here. cc @maleadt

[StefanKarpinski]

None of the failures seem related to this change (a lot of random tests with no seed being set—tsk, tsk) and a couple of segfaults, which are troubling but unlikely to be due to this.

[simeonschaub]

What is the current state on this? Is this acceptable minor breakage for a next release, or do we need to deprecate this syntax in whitespace sensitive contexts for a intermediary release?

[stevengj]

Seems fine for a minor release to me.

[StefanKarpinski]

Just needs a rebase and merge after CI passes.