>>21
Sorry for taking so long to reply.
> Things I'd love to see:
> * Null-terminated strings eliminated in favour of Pascal-style strings. In other words real strings, not an error-prone pointer hack.
There are open source standard C libraries for that. Why don't you use these? I disagree with you in this.
http://bstring.sourceforge.net/
> * The standard library cleaned up. Since strings know their length and are 8-bit clean, you can throw away some function and merge others. Also, function names and arguments can be made consistent.
strings know their length? I don't know what that means. Unless you take point 1 as implemented, but I disagree with point 1. I have to disagree with point 2 as well.
strings are not 8-bit clean. CHAR_BIT in ISO 9899:1999 is required to be at least 8, but it can have a value greater than that. POSIX.1-2001 guarantees CHAR_BIT to equal 8.
> * Get rid of trigraphs.
I disagree. They are not that annoying.
> * Some form of local type inference.
What exactly is local type inference? Can you give a C example of what you have in mind? I did google it, but the results I got from wikipedia were disappointing.
> * I'd love to see computed gotos and labels-as-values become standard.
Once more I do not understand. What makes you think you can not have a "computed goto" in C? What exactly do you have in mind? Example again please.
> It'd still be C (other than the type inference), but it'd be a less error-prone and more pleasant language to use. The only reason I'd call it "2.0" is because the new standard library wouldn't be backward-compatible.
Your only issue as I see is bstring. Use bstring then. For me strings were never an issue, but C was my first language. Were do you come from?
> I'm undecided if strings should support Unicode. Unicode's the future, and it'd be nice to put unicode in string literals and have it Just Work, but have you seen the size of ICU? An is to make strings use machine words instead of bytes and leave ICU separate.
string literals do "support" unicode.