> Structure Prototypes: This was proposed in February 1998 in comp.std.c by bill@cafe.net (Kaz Kylheku). The idea is that eliding member names in a structure prevents access to the members.
This has no chances of going mainstream, but this is a thoughtful and careful exploration of a C extension. Type system [1] is nicely done (though I think it looks a bit clunky in application).
Tangentially related - once you worked with C long enough, the lack of of "templates" becomes pretty obvious. If you need two functions that do the same thing for two different input types, you have two options - wrap it into a multiline define or use one generic function and use a callback to deal with type differences, a'la qsort(). Neither is exactly ideal.
Does anyone know of C dialects with some form of template support?
> Does anyone know of C dialects with some form of template support?
C++, but I'm sure it's not the answer you want.
It would be nice if C++ compilers had more fine grained switch to activate only functionality people want to use. It would be better, IMHO, than creating a new incompatible language each time. A "C + template" would be useful for many people who don't want the full C++.
Most of the C++ features does not require compiler to add anything extra to the binary, there are however some exceptions from this rule, e.g. exceptions (no pun intended) and RTTI.
The biggest problem with using full C++ as C + <small subset of C++ features> is that at some point people will stop writing in C style and start to use STL and design code using C++ idioms. You can probably try to fight this with coding standards, linters and other tools but policing people will require some additional effort.
Just never put STL into your environment. What's what I've seen at a number of C purist dev shops. At first, younger C++ developers complain about the missing STL, but if they actually know how to write the algorithms STL provides, their complaints die after some ribbing from the old guys. It's actually something of beauty when a developer realizes how much of a crutch STL had been to them, and the ease of working without it. Code complexity reduces too, because STL seems to encourage creating complexity over simplicity. Teah, it's not supposed to be that way, but we live in the real world.
I'll be the last one to say the STL (or, rather, its standard library port) is pretty, but damned should I be if I need to reimplement the same data structures and algorithms over and over.
Parametric polymorphism is something every statically typed programming language should have in 2015. I'm aware templates aren't quite parametrically polymorphic, but it's still better than nothing.
C lang has certain features that C++ doesn't. Most notably the "restrict" keyword to make the compiler aware that you don't intend to alias a pointer. AFAIK there is no portable way to do this in C++. This is relatively important feature in HPC. So yeah, I'd very much support the idea of "C plus templates", at least in my field this would get a lot of usage.
UB is not something that a competent programmer does intentionally.
You shouldn't ever run into a situation where you'd tell your fellow programmer, "Hey, on line 300 here, you're doing UB, stop it", only for them to say "No, I'll do UB if I please".
With C++ on the other hand, you could very well run into situations where you plead with your fellow programmer, e.g., "please stop overloading operators in this opaque and unmaintainable way", and then they tell you, "so what, that's our in-house style and it has official language blessing".
Yet even the most competent programmers will have UBs crawl into their code where they do not expect them. Sure, C has less pitfalls than C++ ; but it has its own as well. (see previous discussion on HN "What is C", John Regehr's blog, ...)
Sadly I am yet to work in an enterprise environment that fully understands the meaning of "competent programmer" in their hiring process, specially for offshore resources.
C++ has roughly the same undefined behaviors as C, plus a bunch of additional ones for the C++ specific features.
Also, you'd be surprised how many stubborn C programmers apparently think that mutable global variables are an excellent and convenient time-saver. (Not that C++ programmers do inherently any better here, cf. Singleton)
Hey, thanks for the credit.