>>235
1. Not any improvement here; many compilers allow inline assembly in ways much superior to this;
2. This would actually worsen things out. Pointer types are required for alignment issues in processors. It would make things worse for both the compiler and the programmer;
3. Bitfields are simple to use, simple to write, highly extensible and even portable to a great extent. Bitfields were not designed to be "DERP BITVECTORS". No one uses bitfields as such. No one probably never needed "bitvectors", and if they did, they would simply have used a couple of words to represent their bit arrays, and shift operations to manipulate them straight ahead;
4. This is so against the overall design of your other suggestions, and the C language itself, it is not even worth an extensive comment;
5. You don't have many clues of how a compiler works, do you? The compiler must look up code references somewhere, and this "lookup" is the compilation itself, even if it is simply compiling a header file, without definitions. Actually that's precisely what happens when you include standard library header files. The fact is that the C language is the compiler's program metadata representation itself; replacing this with other form of representation (which would be required anyway) is unnecessary and removes flexibility, because C compiles fast enough to be used as such;
6. C shouldn't be what you think it should either. There's a reason why C is a language in which you actually
can write unportable code. There's a reason why libraries exist. There's a reason why most people frown upon suggestions to "evolve" the language by stuffing them with "extra native functionality";
7. What? You must be kidding. You must be either a troll or must've been completely stoned when you suggested this. Excuse me. Do you know C at all?
8. Agreed. Wow!
9. Really? How would one design such a language feature without either breaking everything else, or removing the overall simplicity and straightforwardness of the language? Indeed, C programmers never implemented "shared pointers", because C programmers never needed them. C programmers write C programs. And C programs are still the fastest and smallest programs around. Think about that for a while, you might reach some enlightment;
10.
sizeof is "native" (whatever the fuck you intend that to mean).
offsetof is standard.
typeof is stupid and vehemently against the spirit of the language;
11. This actually seems reasonable from your other suggestions, since casting is most useful for pointers anyway (and you "wisely" decided to remove all pointer types from the language). Otherwise, braindead, as one would quickly infer from the already stabilished pattern;
12. I'm starting to believe you don't have a single hint what C really is (or C++, or even other programming languages);
13. Another stupid suggestion. There are a number of ways variadic functions access their arguments. This would simply worsen things out, as expected;
14. Incredible. My comment in #12 seems to gain even more evidence. You
do not have a clue what C is all about;
15. What?
15. WHAT?! You're stoned. You're
definitely high as fuck. Not even raw stupidity can explain such a suggestion;
16. So, it means you have simply ripped the ISO standard apart. It also means you don't have a clue (wow!) of what a standard is, why does this kind of document exists, and why what you say is awesomely nonsense;
17. Interesting. I rather agree with this. Look! Many compilers implement things good enough in this aspect. You're really a visionary, ain't you?
18. Again, stupid. Registers do not simply work as in-processor variables you can operate on freely. Specially in CISCs, registers have specific purposes and not every register can be used on every operation; making them look generic is not simply stupid and inefficient, but conceptually wrong;
19. This will cripple language semantics, much like everything you've suggested so far. One program would behave differently from another which look exactly the same simply because one decided to mess with "DERP PRECEDENCE OF OPERATORS";
20. This would remove much flexibility (libraries are selected at link-time, they may be changed to whatever you decide when you compile the program), since the language is unaware of "libraries", and it
should be unaware of libraries for that reason and many others;
21. Agreed in a tiny part. Many standard library features are better used as it is: library features. You must understand one thing: language is a relation between syntax and semantics, not "derp functionalities" piled up within specific syntactical kludges. This is why C and Lisp are real languages, and "Python" and many others are abominations. Probably the only parts in which it would make sense to fit inside the language are some very specific macros (
offsetof and
NULL, for example) and type definitions, which are always used and fit well in the overall grammar structure. But actually, the way it is now works exceedingly well for making people even bother about these ridiculous issues;
22. This would be interesting if serious, experienced people didn't care about bloating their code with data they can simply load during runtime anyway, much more efficiently (since it wouldn't pollute the address space with the entire file content). If the data is small enough to avoid this problem, it would be typed in the code as an static array;
23. Simply useless, and even confusing; the idea of a preprocessor is to do
simple preparation tasks, it is not a metaprogramming tool. C is not Lisp;
24. Great. Now every type will look syntactically the same as a structure. This surely is among the worst suggestions made so far;
25. What the fuck do you mean by that?
Seriously, dude. No offense, but you really,
really should avoid pot when posting online. And maybe study something before trying to "fix" a 40-year old language.