You still can upgrade the block to an actual function and then it works.
Zig doesn’t want to be a kitchen sink language.
This would be the first operator that conditionally evaluates one of its sub-expressions. I don’t think, just adding features from other languages for more terse code is that helpful, if it doesn’t fit the overall design.
It is also a local thing that you optimize, but why would you have these operators all over the place? (which would be a reason to make it more terse)
I think the code can just be rewritten to avoid needing the same pattern.
If something appears many times you probably can come up with a way to write it differently so that part doesn’t need to be restated over and over again.
I am happy that zig doesn’t strive to become the best code golf language.
I also don’t see a huge benefit in terse-ness, I think APL family languages are interesting (was trying to find a modern version of it I came across like a year ago, but can’t remember what its name was, it had an interesting interactive editor that allowed you to write the name of the function/operator and it would then change it to its glyph, basically teaching you the glyph meanings) and they are very terse.
Maybe we can start a brainstorming topic on expressions/functional-style etc.
Personally I find syntax more and more boring, I am more interested in interesting semantics that have a big impact on how you think about things. So I guess I am more interested in paradigms and computation models then syntax.
The discussions about syntax seem short term and surface level, when they are disconnected from a discussion about semantics and the computation model, the latter seems more important for coming up with a overall vision for the language and without that, the syntax suggestions aren’t grounded in something beyond personal preferences.
Your suggestion makes me wonder, whether you want more of a functional language, where you can build up bigger and bigger expressions with operators. I think zig actively tries to avoid/discourage going towards something like that, encouraging you to instead separate the pieces into separate lines, naming the intermediary results.
With something from the APL family, you go towards another extreme, you don’t even use named parameters anymore, instead you combine functions/operators together (although I guess there are ways to instead select things based on position, swap things around etc.).