Sizeof is surprisingly difficult to parse in C

> (everything here also applies to c2y's newly introduced _Countof)

Stop the press, they're adding what? So I don't have to keep adding #define count_of(arr) (sizeof(arr) / sizeof(*arr)) to every codebase and living with its failure modes?

I'm really loving C's character arc at the moment, where they keep going back to fix old problems instead of piling everything and the kitchen sink into the language.

    int func (int arg[static 5])

It's a unary operator, kind of like ~ or !, which can apply to parenthesis (), until it meets a type, then the parenthesis are mandatory:

    int x;
    sizeof x;     // okay
    sizeof (x);   // okay
    sizeof int;   // not okay
    sizeof (int); // okay

It's a weird double rule to parse, but even worse, the strongest binding precedence typically doesn't like an alpha identifier at that point in the recursive descent, so you get weird rules like:

    read_prefix():
        is peak() '!': ...
        is peak() '~": ...
        is alpha(peak())
            maybe alpha is sizeof?
                wait, it wasn't sizeof? it was an identifier? long rewind
        is peak() '+': ...

Something like @ would've been a good pick for sizeof.

\ramble on

(actually, better yet, it should've been used instead of & for taking the address). Imagine:

    int x;
    int* p = @x;

\ramble off

I feel like what you struggle with is expression parsing, not sizeof itself?

Wait, they added a new operator and didn't fix that parsing stupidity by always requiring parentheses?