The specific details aren&#x27;t too important. (Another example: &quot;(T)-1&quot; - very different interpretations depending whether we previously had &quot;typedef int T&quot; or &quot;int T=10&quot;). The problem is that a line of code can&#x27;t be understood, not even at the most basic level of dividing it up into appropriately-categorized tokens and arranging it an appropriate tree-like structure, without having previously interpreted (to some extent) the code that precedes it.<p>From a practical perspective, this makes the compiler code more complicated, because now the parsed code has to be analyzed and the results fed back to the loop. As well as the obvious negative effects of code that&#x27;s more complicated, this also means any code analysis tools that work with source code have to themselves do this same work. (For C, this probably isn&#x27;t too much of a difficulty, but it&#x27;s still annoying having to keep track of typedef names and so on just so you can parse it! For C++, it&#x27;s a very big problem indeed, on account of how much stuff you have to keep on top of - and that&#x27;s why C++ source analysis tools basically never worked properly once you got past a certain level of complexity until people started just using the compiler to do it.)<p>I don&#x27;t have an in-depth background in this stuff, so it&#x27;s possible there are also more abstract benefits from having a grammar that doesn&#x27;t suffer from this sort of problem.