# i_:0|1 varies in v12.1: incompatible change or bug?

Just check

i_: 0 | 1 // FullForm


In v12.0 or earlier the output is

Alternatives[Optional[Pattern[i, Blank[]], 0], 1]


But in v12.1 the output becomes

Optional[Pattern[i, Blank[]], Alternatives[0, 1]]


Seems that the precedence between : and | varies in v12.1. Is this an intentional change, or a bug?

Some more observations. Behavior in v3:

Behavior in v2.1:

• I suspect that this was a bugfix. Try running the same in command-line mode, or try ToExpression["i_: 0 | 1 // FullForm"]. It parses the same way as in 12.1.1. I expect this fixed an inconsistency between the FE's and the kernel's parser. – Szabolcs Jun 30 '20 at 6:14
• I wonder how you came across this example. I can't see a reasonable use for either (i_ : 0) | 1 or i_ : (0 | 1). – Szabolcs Jun 30 '20 at 6:23
• @Szabolcs It's a simplified example of course. I found this because it breaks my code here (see revision 6 ): mathematica.stackexchange.com/posts/132713/revisions . Your guess looks reasonable. Post it as an answer? – xzczd Jun 30 '20 at 6:26
• @sza Aha, here comes another broken example: mathematica.stackexchange.com/a/29366/1871 – xzczd Jun 30 '20 at 10:04
• Actually the 2.1 screenshot answers a question for me. Because when I saw the FE implementation, which dated back to the very beginning of the box parser, I couldn't figure out why it was done that way...in obvious contradiction to the docs. But your 2.1 screenshot suggests that there was actually a change to the kernel (and maybe the docs as well) from 2.1 to 3.0. Maybe the box parser, which was implemented in 3.0, was based on what would become out-of-date info from the kernel. The box parser was implemented maybe a year before I started working on the FE. – John Fultz Jul 1 '20 at 17:05

I expect that this was a bugfix that corrected an inconsistency between how the Front End and the kernel parse this code. Here's a comparison from M12.0.0:

In[1]:= \$Version
Out[1]= 12.0.0 for Mac OS X x86 (64-bit) (April 7, 2019)

In[2]:= i_: 0|1//FullForm
Out[2]//FullForm= Alternatives[Optional[Pattern[i,Blank[]],0],1]

In[3]:= ToExpression["i_: 0 | 1 // FullForm"]
Out[3]//FullForm= Optional[Pattern[i,Blank[]],Alternatives[0,1]]

• Seeing the behavior of v2.1 , I'm a bit confused which change should be regarded as bug... (Check my update. ) – xzczd Jun 30 '20 at 7:09
• @xzczd I would always give the kernel's parsing priority because that is what is being used when a package (i.e. a plain text file) is loaded. – Szabolcs Jun 30 '20 at 8:07
• There's no need to guess here, or pick favorites between the kernel and the FE. The documentation trumps everything. Any variation from the documentation is always a bug (it might be a bug in the documentation, of course, but in practice that's pretty rare). reference.wolfram.com/language/tutorial/OperatorInputForms.html And, yes, it was indeed an intentional bugfix. Three external users had reported some variant of this, and IIRC it came up on the Redmine, too. – John Fultz Jul 1 '20 at 16:55
• @JohnFultz So, the behavior of kernel is an incompatible change of kernel in v3.0, and the behavior of front end is a bug introduced in v3.0 and fixed in v12.1.0? – xzczd Jul 2 '20 at 2:22

I think V. 12.1.1 is correct, because the precedence of Alternatives (|) is larger than that of Optional (:)

Precedence /@ {Alternatives, Optional}

{160., 140.}


This result of Precedence is obtainable both in V. 12.1.1 and V. 12.0.0 (no V. 12.0.1 at hand). So it looks like a bug in V. 12.0.x when interpreting shorthand symbols.

• "it looks like a bug in V. 12.0.x" No, the behavior is much older than you thought. See my update. – xzczd Jun 30 '20 at 7:06
• @xzczd So what would Precedence return in those much older versions? – Αλέξανδρος Ζεγγ Jun 30 '20 at 7:12
• Same result in v3, but there doesn't seem to be a Precedence in v2.1. – xzczd Jun 30 '20 at 7:14