3 ms·
This could make sense for a from-scratch language, but C3 is trying to be an evolution of C, and such constraints would make it so much of a different language
by lerno 1y ago
This could make sense for a from-scratch language, but C3 is trying to be an evolution of C, and such constraints would make it so much of a different language that it would be way out of scope.
I think Rust and similar languages fill that niche already, so there is no real need to try to offer that type of alternative.
- aidenn0 1y agoI think we are miscommunicating. Let's imagine a language called "C@" where the only difference is that "@" is used in place of "*" for a non-nullable pointer type: typedef struct { foo @*data; //Non-nullable pointer to nullable pointer of foo size_t size; size_t fill; } foo_vec; void foo_vec_push(foo_vec @v, foo @x) { if (v->fill == v->size) { //realloc and zero data } else { data[idx++] = v; } } foo @ foo_vec_get(foo_vec @v, size_t idx) { if (idx < fill) { return (foo @)(data+idx); } else { abort(); } } I'm not sure how this constraint makes it "so much of a different language" at all.
- lerno 1y agoIn this case, how would you prevent the user from seeing an invalid foo_vec before initialization? This is either "oh, it's in an illegal state", in which case it's just an annotation without deeper enforcement or you need to somehow enforce that a non-null pointer is never seen, am I not right?
- aidenn0 1y ago1. It's not quite trivial to statically disallow use-before-initialization, but it's definitely a solved problem if you disallow returning uninitialized variables. 2. The other option is to disallow declaration without initialization of non-nullable values. If you can't declare an uninitialized foo_vec, then the user can't ever see an invalid foo_vec.