Comment by nine_k | Hacker News Reader

Comment by nine_k | Hacker News Reader

Parent Full thread

OK, don't call it C, call it C[*].

It will accept any existing C program unmodified.

With a per-file switch, say, #define __FEATURE_WEAK_ARRAYS, it will start to discriminate T* and T[], make it an error to mix them in assignments, or to pass one instead of the other if both the function definition and the function call are in files with this feature on. It will not complain about functions defined elsewhere.

Then, say, #define __FEATURE_STRICT_ARRAYS the compiler will complain about mixing arrays and pointers as function arguments, no matter where the function is defined. It would require updated stdlib headers, for instance.

Additionally, #define __FEATURE_MULTI_ARRAYS would enable syntax for fixed-size multidimensional arrays, Fortran-style. Now uint8[3][2][10] foo; would allocate 60 elements, and access to foo[1][2][3] would involve one memory dereference, not three.

More support would be needed: sizeof, support for slices, safe array copies and length checks. Nothing extraordinary.

Having this implemented would make a terrific master's degree work.

There are a million little places in existing codebases where you start with an array, and then you work with pointers to elements inside the array. So it may be a lot of work to retrofit some of your existing code. If you are not retrofitting enough of your existing code, then you’d be serving greenfield projects—and greenfield projects can use Rust or something.

There are also probably a ton of edge cases you haven’t thought about yet. For one thing, your T[] would be a different beast depending on where it appears—if you declare a variable in a block as T[], it’s an array, but it sounds like your proposal has different semantics for T[] in function parameters—it’s a reference type.

    void f(int x[]) {
      int y[] = {1, 2, 3};
      y = x; // is this allowed?
    }

I’m not trying to fight over the specifics of your proposal. I just want to illustrate that the language design is a tapestry, and you’re pulling at one of the threads.

There are a few proposals I see like this that circle around. This is not the first array improvement proposal I’ve seen for C. There are also lambdas / closures, which are surprisingly untenable in C when you really dive into it. There’s sum types / discriminated unions in Go, and higher-kinded types in Rust. For each of these features, you can find languages which already have these features, giving you all sorts of templates for how to build it, and yet it’s still such a pain in the ass to add these features to the languages which lack them.

It’s more complex than that in practice. You need to support variable length arrays, which means you need to pass length information with the pointer, which doubles the size of array arguments. And that has ripple effects; you can’t do that indiscriminately without memory bloat and severe runtime impact, so you need to annotate argument. And you don’t have complete memory safety. And it takes a lot of manual programmer effort to get there.

This has been studied for decades; there have been many attempts to build a safer version of C. And eventually the C standard committee will have to decide on an approach or lose out to newer languages at an increasingly accelerated rate.

The fun part here is that most allocators already keep the size of the chunk within the header of the chunk, before the pointer they return to the caller of malloc(3). (Yes, jemalloc does not, it keeps the size info in a different way.) BTW I mentioned this as a master's graduation project, not a realistic way forward, because, well, it's not needed.

I'd say that C will lose relevance slowly, more and more, as much as Zig will gain relevance, hopefully to the point of becoming the default choice, and having key parts of Linux kernel ported to it. Not Rust, which mostly replaces C++; even though it can venture on the C territory, its not comfortable nor seamless there. Zig is so seamless, it can even compile your C code along the way. It can do gnarly stuff like handling memory-mapped control registers with relative ease, and with much fewer footguns than C.

C is old, and its age shows. It needs to gradually retire, the way Fortran-77 did.

> C will lose relevance slowly, more and more, as much as Zig will gain relevance

I have felt a bout of nostalgia for the years past reading this.

Rust always passes slices as (ptr, len), and it seems to have to runtime performance impact.

What impact are you thinking of?

GP claimed that passing arrays as (ptr,len) would have a dramatic performance impact. I used Rust as a counterexample.

Oh! I think you had a typo: “to” instead of “no.” I thought you were saying there is a performance impact. Thanks for clarifying :)

I didn't notice, thanks. I agreee that made it confusing.

*no runtime impact

Why do you think that foo[1][2][3] requires more than one memory reference?

AFAIK in regular C a T[][][] foo would be a the same as T ** foo, so it gets implemented as a pointer to an array of pointers to arrays of pointers, each pointing to contiguous allocations of multiple Ts, each not necessarily near the other. So you need three dereferences to get to an element.

  T value = foo[1][2][3];  // becomes:
  foo ->  (T **)
          (T **) -> (T *)
          (T **)    (T *)
          ...       (T *) -> (T)
                    (T *)    (T)
                    ...      (T)
                             (T) <-- This one!

This allows for jagged arrays, yay! So useful.

This is in stark contrast to a Fortran-style array, which is allocated as one contiguous piece, all dimensions folded up for linear access with one dereference.

You are mistaken there. An array `int arr[10][20][30];` is a single contiguous (stack) allocation.

I recommend you read up on what pointer decay actually does; it's more complicated than replacing all arrays with pointers!

In particular, the type of an `arr` expression (after decay) is `int(*)[20][30]`. Decay only ever changes the top-level (outermost) type! And the type of `&arr` is even `int(*)[10][20][30]` -- using `&` or `sizeof` prevents decay from happening. Pointers to arrays are rarely used because using decay is more idiomatic (and because their syntax is unwieldy), but they still exist and would be safer than using decay.

Nope.

Reply on news.ycombinator.com