| 1. Works perfectly in Java. Note that in Java vars are both initialised to known empty values and not initialising a var explicitly in a local scope is an error. If the compiler can't prove your code is correct, then it's not obviously correct, which means I have to sit down and carefully think about if it's correct or not. Just write simple code. Though I concede that pointers make things very hard. Let's say you have void foo(int*);
void bar() {
int x;
foo(&x); /* Is this an error? */
}
You can't tell if x will be initialised or is expected to be initialised. You don't even know if foo will read one int, or expects an array of ints. I would have really preferred it if they did something on that front. Maybe have to declare foo(int[n] a), which you then call as foo([1]&x). There was a paper on extending C with exactly this - though their syntax was foo(size_t n, int a[n]), but I haven't been able to find it. One big plus is that you could, when compiling in debug mode, insert checks for every access. In general, I really want the successor to C to disambiguate between pointers and dynamically-allocated arrays.4. Same reason C++ added nullptr (and I really wish they'd use the same keyword) - if you have a function int foo(int), foo(NULL) compiles fine, but foo(nullptr) doesn't. In C++ especially, since pointer types require casts, so NULL can't be ((void ptr)0), it must be just 0. Once you disallow casting a void ptr to any other ptr, you run into this problem. 5. This is more a problem of C's strings being naked pointers to chars. Every serious piece of code I've seen uses some sort of string wrapper struct. Though they might want to alias char to uint8, for this. 6. Function types should really be pointers, I agree. 7. yeah... 8. Practically every other language does it. It's kind of ludicrous to want every function declared before its usage, when the compiler can just collect all declarations, then see where they're used. 9. I think that's about the right level of granularity. Seems like you'd use struct embedding to separate the public and private fields, e.g. type Foo_priv { private fields }
type Foo { public fields; Foo_priv priv; }
The fact you can't create a Foo from outside the module seems like a bonus to me.10. I'd be in favour of enforcing Java's "project directory structure must mirror module structure", i.e. module a.b.c's files are all in src/a/b/c. I've heard a lot of C# devs lament that the files for a certain package are strewn everywhere. 11. Kind of a sore point, but yeah. I think emulating Java would be the right thing again - give the compiler a list of dirs which to check for compiled modules when doing module resolution, say where the output directory is. 12. yeah 13. Sounds like #pragma. You can't really escape the fact that when you have N compilers for your language, every one will support its own extensions. 14. I think his point is that the language makes these tools easy to write. |
A C string is a sequence of characters, not a pointer. C strings are manipulated using `char*` pointers.