[tom_]

You also run into problems with a=*p and a=-b, which are perhaps more likely.

[zeusk]

But they could've fixed that by going a=(*p) and a=(-b);

Kind of how we use (*p)->next instead of *p->next where p is node_t**

[kdmccormick]

That seems a little backwards and barbaric, though right?

Imagine if we had to watch out for this as a common pitfall:

    // BUG! Actually subtracts x from current val of neg_x.
    neg_x = -x;

Even moreso, how would these two lines behave? Would they differ in semantics?

    n = -5
    n =- 5

Overall, -= is just so much less ambiguous.

EDIT: To your point about ->, I personally think C would be better if:

    *p->next

parsed as:

    (*p)->next

instead of:

    *(p->next)

but maybe now I'm not thinking through all the parsing impliciations :)

[tom_]

I've found struct fields that are pointers far more common than pointers to pointers to structs, so if nothing else it feels like *(p->target) is a more widely useful interpretation of *p->target than (*p)->target would be.

Regarding "n = -5", it would presumably be interpreted as "n=(-5)", same as today. Operators don't have spaces in them. So "n- -5" is "n-(-5)", rather than "n--5" (not valid).

[zeusk]

As you note in your edit; we already have to watch for that pitfall :)

so really the best way out is to be as verbose as possible imo; a = a + c or auto nodep = *nodepp; nodep->next;

Compilers and compute performance have grown to make the difference negligible for code output and compilation times but they definitely take a lot of mental complexity out of such scenarios (anything helps when grokking 10k+ lines of code).