I think ANSI C struct initialization is considerably more readable really. If there are enough members that it gets confusing then tab formatting the values along with a field name comment at the top works great. As for arrays, I don't see how designated initializers really offer anything interesting. Sparse array literals aren't really a pragmatically useful thing in my experience.

I'll allow of course that they don't "ruin the language" they just increase the cognitive burden of reading code.

It's a substantial quality of life improvement to be able to express things like:

  vv = 3f_add(&v, &(3f_t){.x = .1, .y = .2, .z = .3 });

vs. having to declare and name the literal 3f_t beforehand, wasting my time and cluttering up the code with noise.

I actually was also thinking that way.

But then, after looking back at my old code, I struggled and crafted my 1SLOC guiding principle. I never looked back.

Wasting time when writing code is actually an investment into future read speed.

I even wrote some time ago about my rationale for 1SLOC https://blog.pwkf.org/2022/09/18/always-optimize-for-dummies...

I agree with the principle, but I don't agree that this is where it applies. Initializing things separately just makes it easier to make mistakes that are difficult to spot and harder for compiler to come up with meaningful warnings. It also doesn't make it immediately obvious to the reader that it's just a value to be passed as argument rather than further operated on.

Yea I definitely need variable length arrays.

First of all - I'm about 50% sure whether this is sarcastic or not. If it's not, then this comment is addressed to you. If it's sarcasm, then consider it as an explanation for everyone else.

Variable modified types are cool - you can use them to cast a raw pointer to a N times N matrix and the math works out - you can just do m[i][j] instead of m[i*N+j].

But the evil part is when you declare variable length arrays on the stack. There are exactly two possible scenarios - either you have an upper bound on the allocated size or you don't.

If you have an upper bound and it is reasonably small, use a fixed length array on the stack - there is no point in saving a few bytes on the stack.

If you don't have an upper bound, VLAs will blow your stack, given the right inputs.

If you need a way to allocate unbounded arrays in a LIFO pattern, which 99% of the time are tiny, use a dedicated index-incrementing allocator, falling back on malloc when necessary. You can even cast the resulting pointer to a variably modified type, so that sizeof math works out

It is unfortunate that VLA type was made optional in C11. It's like throwing the baby out with the bathwater. Luckily, they decided to make it mandatory again in C23 again, with only the automatic allocation optional.