It's ironic that Musks two big successes were funded by the Obama administration against vehement Republican objections. Shelby repeatedly tried to kill Space-X and without the $400million DOE loan Tesla would never have been able to start production - and without the electric car tax credit - it never would have been able to sell.
It's interesting how often people repeat this argument as if it were persuasive. The compiler developers and Standards writers made an engineering decision which is hard to justify so most people who support it don't even try.
Good explanation of my overly terse note.
The current standard interrupt architecture imposes enormous latency and the synchronous timer could be more precise. The simplest implementation would just "fetch" jmp every N instructions (with N programmable) - just like voluntary switching but where the processor would volunteer the program.
A) there is no evidence such phenomena - especially in net- are due to unsafe optimizations, b) those companies dont need to shift their costs to other users
Your argument would be more compelling if programming languages with higher level iteration primitives were significantly more optimizable than C. The underlying processor architectures have loop indexes. Just pretending you can do applicative programming doesn't mean you can. C is very adaptable - even to GPUs. Also, I have yet to see that decent memory model.
There was no size_t in K&R1. Size_t was introduced in the standards process as was the definition of index variables in the for loop. You may have a complain with the standard there.
As for the optimization, it is based on misunderstanding of C semantics. The only place where the sign extend makes a difference is where pointers are longer than "ints" AND where the the iterator can overflow, and in that case, sign extend only makes a difference if the loop is incorrectly coded so that the end condition is never true. The code should just provoke a warning and then omit the sign extend (and it almost certainly doesn't make much of a difference since sign extend is highly optimized and has zero cost in a pipelined processor).
This proposal is moving through the C standards process and I was curious about whether people think it is a good idea. It appears to have a lot of backing in the Committee ( I am dubious, but I think I am in the minority).
If there is interest, I will also publish links to other proposals that are moving forward in the C23 process.