This paper [1] should be required reading for all would-be C replacement authors who don't want to follow in the footsteps of their unsuccessful predecessors. A

This paper [1] should be required reading for all would-be C replacement authors who don't want to follow in the footsteps of their unsuccessful predecessors. As for my two cents, the design of modern programming languages seems to be based on a premise of distrust for the programmer, but the designers appear to have forgotten that the distrust goes both ways. In [2], an old book about C programming, readers are reminded that rarely used language features incur the risk of the compiler writer not having implemented them correctly. It's unlikely that any fancy new feature would make me prefer your C replacement because I don't even use all of the features of C most of the time. That being said, if you're crazy enough to write a C replacement in the first place, then maybe you'll be crazy enough to incorporate my crazy suggestion for function specialization. In functional languages, given a function f(w,x,y,z) with many parameters, it's straightforward to define another function g(a,b) with fewer parameters as being equal to f(H,b,a,K), a more general function specialized by fixed constants for some of the parameters and arbitrary permutations of the others. I'd like to be able to express the transformation that takes a pointer to the general function f as input and returns a pointer to the specialized function g, such that the pointer to g can be used in the same context as any other pointer to a function of that arity and type defined the normal way. I'd like it to be possible in a library written be me operating on user-supplied pointers to functions not known in advance, I'd like to avoid workarounds such as global static variables or thread-specific storage, and I'd like you to convince me that your implementation of this feature is too simple to be wrong. [1] "Some Were Meant for C" by Stephen Kell https://doi.org/10.1145/3133850.3133867 https://doi.org/10.1145/3133850.3133867 [2] "C Traps and Pitfalls" by Andrew Koenig edit: typo