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 b

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.