1. Type safety for generic interfaces such as qsort. 2. Language interoperability. Then you need to have a dynamic framework for constructing types and function calls.

Hi Martin, thank you for writing this proposal. This is just my two cents, but one-off void* functions, like qsort, are less of a pain point relative to generic containers. With generic containers it's common to have a collection of void* functions that must be consistently invoked with identical type T. Correct me if I'm wrong, but this proposal cannot genericize a struct field, i.e. it can genericize type 'T' but not 'T->someField'. The latter would be useful for something like 'vec_push(v,p)' where 'v->data[]' is the type T needed to determine if 'p' is a compatible type.

Tangentially related, the macro-based containers you've written here [1] are the best answer for type-generic containers I've come across. One "gotcha" is the container name must be a valid C identifier otherwise it doesn't token paste correctly (see Example #2 of your REAMDE where you typedef'd string* as string_ptr to workaround this). Would you give consideration to a new preprocessor mechanism for concatenating a list of tokens into a single valid C identifier? i.e. Something like CONCAT(struct Foo *) would produce struct_Foo_Ptr? The result is guaranteed token paste-able.

[1] https://github.com/uecker/noplate

Thanks. I agree that data structures are even more important. So I plan to make this for for data structures too (this is not a full proposal yet, just testing the waters):

#define foo(tag, T) struct tag { _Var(T)* p; }

then we also need a solution for the problem you mention. One option I thought about is to allow strings as tags: https://godbolt.org/z/cMc3aPjsK And if the builtin that transforms types to strings you be used as a string literal, this could work nicely. But even better may be to just all parametrizing the tag with a type: struct foo(T)

I am still thinking about this.

If you’re in a situation where you “truly need” type safe generic interfaces, why wouldn’t you just use a different language?

I don’t understand your second point.

The other point: For interoperability with other languages you often need to construct function calls at run-time. For this one needs to be able to describe types. Adding this by external libraries is always a pain because one has to carefully support the ABI of all supported architectures. A compiler can support this seamlessly. A _Typeof operator that returns a type that can be passed around and interrogated at run-time solves this in a very elegant and simple way.

There is no other languages with the same advantages as C and a good type system.

What advantages do you have in mind? Why not just use C++, Ada, or Rust?

Generic libraries. There are programming domains in the embedded world where code reuse can shorten the development timeline in a significant way, which gives engineers more time to test and verify.

Example? Why not just use C++?

Because there are platforms with no, or really buggy C++ support.

That sounds like a someone else's problem. Find a platform that supports the language you need rather than try to make C into that language.

It is not C's job to be everything to everyone.

What is an example of an embedded systems project which truly benefits from a generic library in the way that you described?

Aviation would be my personal experience. We have to implement services on the aircraft for structured communication support with the ground tower. Those would really benefit from something like that, since we wouldn't have to implement a backend for every project and we could simply reuse the whole library everywhere.

I don’t see how generic programming (a la polymorphic types as presented) is the only or even the best solution to this problem.