C, for the level of abstraction it targets is an extremely good language, and this is the reason why it is still alive, and why a lot of big successful projects are written using C. The problem is its standard library. The "get this new language" teams should instead focus on how to incrementally improve C. D was a (bad IMHO) attempt, just retry and make it better, a step after the other. If we will wait the ANSI committee we can all get old with strcpy().
IMHO one of the few things that should be addressed at language level is that structures with function pointer members should have a way to be called with the implicit structure pointer (something like "this") as argument. That's all we need from OOP for C. This makes you able to do:
list *mylist = createList();
mylist->push(foo);
mylist->pop();
Agreed completely. I'm doing a decent amount of development with MCUs these days and really like having a minimal abstraction. It's easier to think about what the hardware is doing when you're only slightly removed from the assembly; what would be a convenient abstraction for most application development quickly becomes a liability as knowing the implementation details can be pretty important (due to limited resources).
As for an implicit "this" for function pointers, I've had the same wish myself. I've settled for just a function namespace (ie: myListPush(myList,foo);) due to the verbosity of your example but it's not quite the same. At this point I'm pretty happy without it, and even think it might be hiding too much information, but it makes a nice piece of syntactic sugar for sure. My current unneeded-but-desired change to C would be the addition of lambdas like in C++11.
I don't think so; I think you also need polymorphism and probably exceptions. I think GC would also greatly improve expressiveness, because it makes functional style much easier to implement without redundant copying. But minimally some kind of polymorphism, and no, discriminated unions aren't enough - but Go's interfaces would probably do. Also, some way of hiding data members that doesn't require obscuring casts would be nice too.
The biggest problems I've had with large C codebases are deep assumptions about data structures, spread throughout. The biggest benefits of OOP, IMO, come from firewalling off internal details from client code through the use of an interface; knowing that client code has to call you, rather than simply follow your internal links, gives you a lot of freedom to change things after the fact. A polymorphic reference that the client can't dereference and poke about with gives you that.
I think the point is "for the level of abstraction it targets". Add all those abstractions that are generally a good thing in a perfect world, and practically you shifted the language enough to be unsuited for many tasks we use it today.
Polymorphism doesn't have to add runtime overhead. You can achieve polymorphism without RTTI through code duplication, as C++ templates do. (You can also use uniform value representations, like C void *, although this is limited in its applicability.)
Code duplication is an overhead. Not as bad as RTTI, but static memory footprint is still important in the embedded/systems world -- sometimes more so than runtime memory footprint!
You don't need any RTTI or code duplication for polymorphism, so long as you don't need general support for type-checked downcasts. If you do need type-checked downcasts, it can be as cheap as a single pointer on antirez's mylist->ops function table - a pointer pointing to the ancestor function table.
(Specific support for any single downcast is trivial - just write a function for the function table, typed appropriately and implemented appropriately.)
It's not an attempt to incrementally build on the C base, it rewrites all the rules, has a GC, D v1 and D v2 are pretty different things, and so forth...
IMHO one of the few things that should be addressed at language level is that structures with function pointer members should have a way to be called with the implicit structure pointer (something like "this") as argument. That's all we need from OOP for C. This makes you able to do:
That's what currently you do like: