News for hackers. Stuff that matters.
Re:Learning C3 by aidenn0 on Thursday May 29, 2025 @05:23PM (#44130539)
I 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.
Re:Learning C3 by lerno on Saturday May 31, 2025 @04:26AM (#44142854)
In 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?
Re:Learning C3 by aidenn0 on Saturday May 31, 2025 @01:40PM (#44145807)
1. 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.