[Elv13]

My comment wasn't about fast "scripting" languages, for whatever your definition of that is. I don't think stronger typing and memory constraint enforcement have anything to do with scripting languages. In my opinion, C lack them by design, not be necessity. A language could, in theory enforce them without runtime penalty and without losing too much flexibility (such as array aliasing).

C++11/14 "auto" is an example where someone can have the equivalent of a void* with compile time type checking and "no" runtime penalty. Yes, multiple specialized version of the method will be created and increase the binary size and potential cache fault, but much of them will (ok, should...) be eliminated/combined again during LTO. A slightly incompatible fork of C could also remove array to pointer demotion, sizeof() would then be consistent and potential overflow would be possible to catch using branch analysis or -fsanitize=.

[StephanTLavavej]

In C++11, auto just says, "make the type of this thing the same(ish) as the type of its initializer". There is no potential for code bloat, even in theory. In C++14, auto can be used for generic lambdas, but even those are almost always called with a single set of argument types, so again no code bloat even in theory.

(Template code bloat itself is nearly mythical. I've seen exactly one occurrence of it causing a problem, in 8 years of Standard Library maintenance.)

[tbirdz]

In my experience code bloat from templates comes mostly from libraries whose authors are much less skilled than those of the standard library.