In a language like Rust, the compiler will “lock” the pointers for you, and you can’t forget.

In a language like C++ (and presumably Zig), one could, in theory at least, have the iterators and slices that reference the storage of a dynamic array hold some sort of lock that pins the storage.

But this API requires the programmer to remember to lock the pointers and also requires the programmer to keep the lock alive for the correct region of code. And it looks to me like even the example in the blog post has the lock taken completely outside the function that requires stability, so there is nothing whatsoever that gets the lock scoping right. Even the type system can’t help — the offending parse function can’t declare that it wants a pointer-locked ArrayList parameter.

So right now, when we want control, we need to give up some safety, but weaker things are still helpful.

Also, in low-level code, the problem of "I might forget to do something" sometimes clashes with the problem of "I need to see exactly what operations are done and where". Various kinds of implicitness help with the former at the expense of the latter.

I'm not saying this is universally better than other approaches, but many people who do serious low-level programming would prefer this.

“I use it in a lot of places where I know the max capacity ahead of time -- ensureCapacity() followed by a lot of AssumeCapacity()-styled commands. It's convenient for all of the ... convenience ... methods (append() requires some bookkeeping somewhere, appendSlice() requires more, and so on). In those usages, it's basically syntactic sugar over a slice”*

I suspect “where I know the max capacity ahead of time” covers most if not all use cases (if it you use this without knowing max capacity, you either accept your code may panic, or you do some unlock, grow, lock again dance when you discover your initial estimate is wrong)

If so, wouldn’t adding a growable container where you specify capacity at construction time and removing access to the internal pointers of ArrayList be a better way to handle this?

Similarly, CPU architectures that use descriptors can (have to?) have languages with that notion.

I use Array list a lot so excited to add this throughout the code to harden them.

I can imagine this is not everyone's cup of tea, but then you probably also wouldn't any if the other explicitness.

At least we got Deque in exchange. I use that far more often than I used SegmentedList.

The proposed change doesn't do much for me personally (memory safety is ensured in other ways, and if it weren't I wouldn't be annoyed debugging the allocator-observed errors), but I could see myself using it at some other point in time for the same class of usages, or I could see other people relying on it when they choose that class of coding.

I recently implemented a custom C++ container for a path whose components could be iterated, backed by a std::string. I just store indices and a reference to the string, such that my iterators are not invalidated if the std::string gets reallocated after being modified. Far less error prone for little added cost.

    const text =
        \\This is a long comment
        \\But I can split it among lines arbitrarily
        \\And keep my indentation.
    ;

    const TEXT: &'static str = docstr!(
        /// Now I can do it in Rust, too.
        /// I prefer this style a lot of the time
        /// for long texts.
    );

    let greeting: String = docstr!(format!
        /// Hello, my name is {name}.
        /// I am {} years old!
        age
    );

Changing a segfault to a panic with a stack trace is an improvement in developer experience. It does not make better software. The advantage of automatic strategies to mitigate memory safety mistakes either by using GC to make the program sound or static analysis to prevent the mistake by construction is plainly better.

There is a direction in some systems programming circles away from this by eschewing "complexity" (in other words, fixing the damn problems) for programs that have better error messages when the programmer made a mistake. I don't see that as better software.