[mtdewcmu]

This is basically a way of obfuscating your C code. If you want to write obfuscated code, C++ has extensive support for this. I think it's actually a strength of C to not have many features. It ultimately makes code more readable and reliable.

[raverbashing]

I don't think I can agree more with your comment.

C++ in fact is only usable (in a team) if its features are pruned and limited in a team. Really

Throw in some fine preprocessor magic and you'll end up with completely unmaintanable and impossible to understand code.

[mtdewcmu]

Yeah. C is a boring language that barely ever changes. But I'm not sure there isn't wisdom in being dull.

[nitrogen]

Compound literals in C are awesome like it's 1999:

Assuming you have this:

   struct point {
      float x, y, z;
   };
   void do_something_with_point(struct point *p);

You can do this:

   do_something_with_point(&(struct point){.x = 1.5, .y = 1.5, .z = 3.5});

[mtdewcmu]

You can take the address of a literal?

Being able to specify a literal for a struct is useful. You can, for instance, put the literal in a macro and use the macro to initialize or reset a struct. It's better than having to write additional functions to do something trivial.

[nitrogen]

Yes, you can. You can use it to create an approximation of named parameters, because struct members that don't have an initializer will default to zero. It's still not nearly as compact as, say, Ruby, but for C it's pretty awesome and fast.

[mtdewcmu]

That's interesting. You know you can pass structs by value, too, so I'm not sure how necessary it is to take the address.

[nitrogen]

Anonymous functions are a way of de-obfuscating code that is heavy in callbacks. Instead of having the logic flow indirectly to some external method that might be far away, the logic can live within one function body.

[mtdewcmu]

Callbacks are inherently going to make a program harder to follow. Without seeing the code, it's hard to suggest other solutions.

[nitrogen]

Some possible examples include qsort() and iterators. You could also use them for event handlers, but those are probably clearer as separate methods.

I haven't used LambdaPP, but I'm guessing you can get around the lack of closures the same way you do with callbacks, by passing a void* with necessary data.

[mtdewcmu]

I'm sure that there are a lot of cases where you could make code look neater and sleeker with this kind of syntax extension, but my thesis -- and this is inherently hard to prove -- is that the uglier code you may have to write in C is nonetheless more robust and maintainable code in the end. A lot of very good software has been written in C, and what I suspect contributes to C's impressive record of robustness is its spare syntax and the fact that there is almost no room for ambiguity and subtle, invisible side effects. What you see is what you get.

Adding simple, inline anonymous functions like these is a fairly modest proposal, of course, and I can't tell you exactly what damage they'd cause. They could turn out harmless. But they are redundant, because C already has a syntax for functions, and that redundancy now forces the programmer to have to make a choice about which syntax to use every time the situation permits them. Reading code becomes a bit more complicated, because there are more kinds of syntactic elements to recognize and know the consequences of. You end up splitting your time between two ways of writing functions, and that works against developing consistent practices and conventions for writing functions.

Is there a trade-off? Probably. It may be too onerous to write some types of code in C, and a little syntactic sugar might be able to make it tractable. But maybe you're better off writing that code in a different language, anyway. C has a good thing going, so why risk messing with it?

[nitrogen]

...almost no room for ambiguity and subtle, invisible side effects. What you see is what you get. [emphasis mine]

The key word there is "almost." C does have lots of undefined behaviors.

[mtdewcmu]

If you don't hedge your statements about programming, you will invariably be wrong. There are always counter-examples.

The kind of ambiguity and side-effects I'm alluding to are ones programming languages explicitly support and encourage, like overloaded operators and overloaded methods in C++. In C, the effects of a segment of code are comparatively predictable just by looking at the code itself. In quite a large number of languages, you can't draw many conclusions about what a segment of code does without looking in multiple other places.