Improve type generic programming

This is a new paper that appeared today on the site of the C committee:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2638.pdf

C already has a variaty of interfaces for type-generic programming, but lacks a systematic approach that provides type safety, strong ecapsulation and general usability. This paper is a summary paper for a series that provides improvements through

  • N2632. type inference for variable definitions (auto feature) and function return
  • N2633. function literals and value closures
  • N2634. type-generic lambdas (with auto parameters)
  • N2635. lvalue closures (pseudo-references for captures)

The aim is to have a complete set of features that allows to easily specify and reuse type-generic code that can equally be used by applications or by library implementors. All this by remaining faithful to C’s efficient approach of static types and automatic (stack) allocation of local variables, by avoiding superfluous indirections and object aliasing, and by forcing no changes to existing ABI.

5 thoughts on “Improve type generic programming”

  1. Hi Jens, is there any chance C could have support of function members in custom types as maybe a syntactic sugar for member function pointers in the future?

    struct Point {
    int x, y;
    void reset(){
        x = 0;
        y = 0;
    }
}

    That would be a dream come true.

  2. From your question I assume that you mean for C to have classes, because your example supposes that behind the reset function there is a hidden object that gets initialized.

    Most certainly not.

    This has been discussed several times in the past, I think, and never made it into C.

    Classes are a whole can of worms, with implicit objects, this pointers, const qualification (or not) and a lot of indirections. This classic model of OO programming has clearly fallen out of fashion since already some time, and for C it is particularly inappropriate because we like to have things explicit as much as this is possible.

    What I’d hope could come some day (but far away) are modules, that is the possibility to group features together in a convenient way that allows to program them and refer to them easily. This not so difficult to achieve and can mostly be done with some textual replacement. For example shnell as I presented in this post https://gustedt.wordpress.com/2020/11/10/c-source-to-source-compiler-enhancement-from-within/ has such a facility.

    1. While I agree that classes in C would be problematic, I would be happy to see a feature where structs act as local namespaces for functions defined internal to them (they do this already in a sense, with their members).

      So, borrowing from the above comment:

      struct Point {
    int x, y;
    void reset(struct Point p) { 
        // would this still need a self/this pointer to be defined? 
        // Maybe make the definition of one explicit if so.
        p.x = 0;
        p.y = 0;
    }
}

      For a struct Point p, we could then call p.reset() (which would only be Point.reset(p) – a coder could write it that way if they want to be explicit).

      I’ll admit though that I am no expert in C. I have no idea if this would be popular or how this would work with name look-ups, functions pointers etc. And I am certainly in no position to assess how a spec/implementation for such a feature would look.

      P.S. I’m also new to the WordPress interface. Not sure how to format code to be more readable – sorry.

  3. Why introduce more and more language constructs from C++ that make the difficulty of implementing C approach that of implementing C++? And these are the kind of constructs that hide a significant cost to its users: code generation and thus ballooning code size. C’s explicitness is a really good feature of the language. I hope this would be optional for, just like VLAs are optional since C11 (__STDC_NO_VLA__).

    (Side note: A while ago I’ve posted a long comment on the core specification v2 post. Was it removed/unapproved for some reason? I apologize if the tone was too critical.)

    1. I don’t like this opposition that you imply in your question between C and C++, and I don’t like the “more and more” either. This series of papers is just proposing a quite reduced and selected set of features that come from C++, yes, but could also be inspired from somewhere else. By no means this introduces C++’s complexity into C. Everybody has their own selection properties that they like in a particular programming language, nobody is forced to use features they don’t like. As the paper states, C has already 8 different forms of type-generic programming, and the weirdness-level that these impose on our programmers is quite high. This series of papers tries to give them features at hand that allow for a more systematic approach.

      For the other post that you are refering to, I don’t have a particular recollection. I am not at all oposed to approve posts that are critical to what I am doing, here, but indeed, I don’t publish posts have a tone that hides the contents. Generally, when that happens I try to contact the author about that, if I happen to find an email address for them.

Comments are closed.