We need a C- ore µC:

No implicit cast except for literals and void* (explicit compile time/runtime casts), one loop statement (loop{}), no switch/enum/generic/_thread/typeof/etc, no integer promotion, only sized primitive types (u64 s32 f32 etc...), no anonymous code block, real compiler hard/compile time constant declaration, many operators have to go (--,++, a?b:c, etc)... and everything I am forgetting right now (the dangerous struct pack attribute...). But we need inline keywords for memory barriers, atomics for modern hardware architecture programming.

  int array[10];
  *(array+1) = 56;
  array[2] = 4;
  3[array] = 27;

The obvious one is rather than a function pointer typedef, such the subsequent use in a struct is obviously a pointer. Which helps when others are initially reading unfamiliar structures.

  typedef int handler_ty(int a);

  struct foo {
    handler_ty *handler;
    /* ... */
  }

  struct foo table[] = { { /* init fields */, /* init fields */, };

  handler_ty some_handler;
  int some_handler(int a) { /* ... */ }

Basically the error would generally directly call out the inconsistency with the prior line, rather than with the distanct use in the initialisation of 'table'.

As I recall this mechanism has been around since at least C89, I don't recall using it in K&R.

C was developed on a PDP-11 that had 64Kb of memory. That's not much of any at all. Therefore, the compiler must be extremely tightly coded.

The fundamental rules of the C language are pretty simple. But articles like these expose consequences of such simple rules. Fixing them requires adding more code. Adding more code means less room for the code being compiled.

Therefore, if the intended use of the language works, the pragmatic approach would be to simply not worry about the quirky consequences.

A more interesting question would be "why do these characteristics persist in modern C compilers?"

The stock answer is "backwards compatibility", "Obfuscated C Code contests" and "gotcha job interview questions". My argument would be that there is no reason for the persistence of such "junk DNA" and it should be deprecated and removed.

I've done my part. D doesn't support that stuff, even though the basic use of the language is easily confused with C.

For example:

    #include <stdio.h>
    void main()
    {
        int i;
        for (i = 0; i < 10; ++i);
            printf("%d\n", i);
    }

The equivalent D code:

    import core.stdc.stdio;
    void main()
    {
        int i;
        for (i = 0; i < 10; ++i);
            printf("%d\n", i);
    }

    test.d(5): Error: use `{ }` for an empty statement, not `;`