[FEAT] Support Mutable variant of Array and map

[tqchen]

As of now Array(and map) are immutable and COW by default, one nice property is it allows us to unify handling of tuple and map. The underlying ABI do support mutable variant as well(with the data deleter field and data ptr). While developers can always wrap ObjectRef variant to be muatble, it can helpful to think about the design choice and bring up support for mutable variant.

[Dayuxiaoshui]

@tqchen We understand this requirement. While the current immutable + COW design of Array provides benefits for unified tuple/map handling, there's a clear need for controlled mutability. We propose adding setitem at the Python layer leveraging the existing COW mechanism, exposing ArraySetItem via FFI. This maintains backward compatibility (arrays remain immutable by default) while enabling arr[i] = value syntax. When the array has a unique reference, modifications happen in-place; multiple references trigger COW. The implementation is added to src/ffi/container.cc and python/tvm_ffi/container.py, ready to use. This approach preserves the semantic benefits of immutability while providing flexible mutability when needed.

[tqchen]

thanks @Dayuxiaoshui , yes get what you mean. We are actually thinking about enabling a possible mutable variant explicitly as another class, since there can be a need of shared mutation. So likely we will go with that path but needs to deliberate a bit of choices before we go

[Dayuxiaoshui]

@tqchen Thanks for the clarification! I understand the design consideration. An explicit mutable variant as a separate class makes sense, especially for shared mutation scenarios. I'd like to contribute to part of the development work for this feature. Looking forward to helping out!

[junrushao]

I have some different thoughts regarding this task as I encounter a few issues. While CoW property is indeed used in a few TIR/Relax passes, it's absolutely an anti-pattern to have such complex semantics if the behavior of a program depends on reference counters which are supposed to be implementation details.

In dataclass's frozen=True mode, there's an inherit need to switch between frozen (immutable) and non-frozen (mutable) instances. In this case, I suspect it would be extremely challenging to convert from frozen (InplaceArray-based) to non-frozen (out-of-place data_ ptr with an extra data_deleter_), mutate, and converting back without resorting to copying. Resorting to copy would incur correctness issues as pointer reference got invalidated.

The benefit of having inplace arrays are minimal and I didn't see a real killer app. Therefore, in my opinion, it's extremely compelling to get rid of this non-standard behavior and convert to mutability first. It means either breaking change, or having a separate List/Dict classes which are standard mutable containers.

[tqchen]

Seems there is consensus that we need mutable array.

[tqchen]

#443 implements the feature thanks to @junrushao

[junrushao]

Closed via #443

[tqchen]

#463 follows up on supporting Map