4 ms·

I don’t like them because they’re easy to write and a pain to deal with later. My biggest irritation comes when I’d like to break inside the if or else clause o

by dgfitz 3y ago

I don’t like them because they’re easy to write and a pain to deal with later. My biggest irritation comes when I’d like to break inside the if or else clause of a ternary and can’t. There is also more mental overhead to parse and keep in the mental stack. I have also seen them used cleanly and beautifully, but that is a rare occurrence.

sylware 3y ago
Something which is significantly "controversial", or has no significant and pertinent impact, should not increase the compiler technical cost. Syntax sugar is the enemy of compiler technical costs. For instance, a "feature" of significant and pertinent impact missing, in the list I provided, load and store from unaligned memory address should have their own keywords as this is really important, even though modern hardware micro-archs tolerate that at a cost. Anybody using that abomination of "struct packing" C extensions should think again: C has been meant for aligned access by default, namely unaligned access should be at a syntax cost, and should pop up from the syntax and be HARDCORE explicit. I don't even think rust syntax is that clean, am I wrong? (hopefully) For instance in linux printf, I did run in a beautiful (irony) "aligned" attribute on a stack variable. I was reading the code and I though there was a bug since I did not read the variable declaration as I was very mistaken that the variable name was enough... Yeah, should be banned from the kernel (hopefully, rust is careful to avoid that abomination in its syntax). When I have "packed" data structures, I am, usually, careful at having everything "byte" defined and use explicit macros for Xword loads and stores. "Letting the compiler do that for you" is dual edge sword. And I don't even start on the _Generic abomination, which creates so much type indirection you don't know what you are dealing with unless you read a ton more code.
IlliOnato 3y ago
What you mean by "breaking inside"? You cannot nest ternaries, but you can chain them (see my other comment above).

by dgfitz 3y ago

sylware 3y ago

Something which is significantly "controversial", or has no significant and pertinent impact, should not increase the compiler technical cost. Syntax sugar is the enemy of compiler technical costs. For instance, a "feature" of significant and pertinent impact missing, in the list I provided, load and store from unaligned memory address should have their own keywords as this is really important, even though modern hardware micro-archs tolerate that at a cost. Anybody using that abomination of "struct packing" C extensions should think again: C has been meant for aligned access by default, namely unaligned access should be at a syntax cost, and should pop up from the syntax and be HARDCORE explicit. I don't even think rust syntax is that clean, am I wrong? (hopefully) For instance in linux printf, I did run in a beautiful (irony) "aligned" attribute on a stack variable. I was reading the code and I though there was a bug since I did not read the variable declaration as I was very mistaken that the variable name was enough... Yeah, should be banned from the kernel (hopefully, rust is careful to avoid that abomination in its syntax). When I have "packed" data structures, I am, usually, careful at having everything "byte" defined and use explicit macros for Xword loads and stores. "Letting the compiler do that for you" is dual edge sword. And I don't even start on the _Generic abomination, which creates so much type indirection you don't know what you are dealing with unless you read a ton more code.

IlliOnato 3y ago

What you mean by "breaking inside"? You cannot nest ternaries, but you can chain them (see my other comment above).