Sure, C could be much better right now. In some incredible way people that are able to drive the future of C made all the worst choices, undermining the language instead of improving it, for most parts (with undefined behaviours).

C just needs:

1. A solid and modern standard library, with basic data structures, sane strings, higher level sockets, ...

2. A very simple object system. No inheritance, no advanced features at all, just the ability to call object->method(1,2,3) and getting a 'self' reference.

3. Ability to perform operations on function exit in order to clean-up locally allocated things. So as I allocate things or open files and alike, I can specify some cleanup code doing things like if (fp) fclose(fp); that is executed when the function returns in any case.

Just as an aside Odin (https://odin-lang.org) has all of these things and does not stray far from C otherwise. It's a delightful language.

There are other OOP paradigms, no need to force 'this' pointers on everyone like C++ does. Both 2 and 3 could be done with semantic-aware macros instead.

I believe the C++ way would be the right thing for C. Note that this does not mean in any way to inherit all the stuff from C++, nor even constructors and stuff like that. Simply a way to avoid doing this:

    list_add(&mylist,1);

But instead:

    mylist->add(1);

Note that doing this is not an option:

    mylist->class->add(&mylist,1);

It's not just ugly (even if often used), but also uses an additional pointer, which in some application (like Redis) is a no-go because of memory usage.

Maybe you would like UFCS: https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax

e.g. Nim has it, and it lets you do this:

  proc add(self: MyList, e: int) =
    # [insert append code here]

  mylist.add(1) # equivalent to
  add(mylist, 1)

Though I'm not sure how well it would work with C, considering it lacks function overloading.

Perhaps, though I think one should be careful, as reproducing C++ in this fashion runs awfully close to reproducing what I see as C++'s largest sin...

Let me explain, I feel iteration speed is of utmost importance. So C++'s mistake of mixing interface and implementation (data layout specifically) leads to massive include bloat, and ultimately contributes significantly to the compilation time problem in C++. In contrast, in C, functions are almost entirely decoupled from structure data layout, and implementation, this promoting much more svelte headers and reduced compilation time for many projects.

So, IMO, it would be important to seperate object interface, from the layout, or risk a major, if not the most major, advantage of using C over C++

If C hadn't been standardized by ISO, I wonder if C implementors would have eventually added stuff like this just because they found it useful.

Or if C had been standardized, but C++ didn't exist, maybe they would have added features like this simply because contemporary languages like Object Pascal and Ada 95 supported object oriented programming better in practice.

I read a paper 'What If We Don’t Pop the Stack? The Return of 2nd-Class Values' where they discuss their research into delaying popping the stack to allow functions to return data allocated on the stack. As a small brained embedded primate that doesn't use malloc that sort of thing would make C vastly easier to use.

https://www.cs.purdue.edu/homes/rompf/papers/xhebraj-ecoop22...

Also would be super if C had first class types.