Apple has extended C with lifetime annotations to try and make it safer. That is against the philosophy of C. You are supposed to have guns pointed at your fingers and toes, individually, at all times. It trains the empathy out of you and prepares you to join the army.
We need more programmers to join the army, so we need C to continue its great tradition of "worse is better," which I will knowingly reinterpret in bad faith to mean whatever I want. In this case it means more stupid fucking footguns that nobody wanted to tolerate in 1972, but C made them acceptable again.
How can we force programmers to treat writing C even more like disarming a nuclear fucking warhead and less like a thoughtful craft with an expectation of productivity?
make C worse
I have a few ideas. First, remove malloc() and free(), and make it garbage collected, get rid of the defining quality of C, this will fuck up the language.
Then, remove all the syntax and make it a uniform soup of nothing but parentheses. Make parenthesese the dominant form of syntactic structure. Make it use polish notation for function application.
And make it dynamically typed while you're at it.
There, you just made C orders of magnitude worse in just three easy steps.
>>2
It seems like maybe the OP was not worded clearly. You are making fun of Lisp for being "better," AKA "worse," than C, which is "worse" and thus "better," but the object of this thread is to make C even "worse" than itself, and thus "better." Do you understand yet?
An example I thought of just now of C worsitude would be how it automatically casts between integers and floats with no way to opt out. This could be taken a step further by automatically casting from a struct to an int/float by taking the value of the first field, or perhaps the first N bytes of the struct.
Passing a pointer to a struct where an int is expected should go even further and try to dereference the pointer (to cast the contents of the struct to an int/float as described above) unless it is null, in which case the result should be zero.
This would introduce all kinds of footguns, which are a "good" thing, in keeping with the essential character of C.
>>3
Oh ok, we want to exacerbate C's inherent flaws, such as by mixing things up.
I like your idea of using pointers to structs in place of more "atomic" (so to speak) datatypes and vice-versa. I would reduce the struct two just two fields: the "first thing" in it, and a pointer to another struct for "the rest", that way you pile up the opportunities to cast pointers to structs into integers and such. We could obviate type signatures altogether so that a function can get either without warning.
>>4
You're doing it again.
I'm going to make the face at you.
>>4
Sounds good, but do make sure that you don't actually call it "first thing" and "the rest", it's better to make up some random characters as names, like pne and pqe.
These guys have been doing this for years https://www.ioccc.org/